From nobody Mon Nov 2 06:14:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D701B3703 for ; Mon, 2 Nov 2015 06:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T1KqKZ2RsI9 for ; Mon, 2 Nov 2015 06:14:05 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1E71B3701 for ; Mon, 2 Nov 2015 06:14:05 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0075.outbound.protection.outlook.com [213.199.154.75]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-12-OMBqUxIWRr6EzXwJkXXwQg-1; Mon, 02 Nov 2015 14:14:00 +0000 Received: from DB3PR07MB138.eurprd07.prod.outlook.com (10.242.132.20) by DB3PR07MB139.eurprd07.prod.outlook.com (10.242.132.25) with Microsoft SMTP Server (TLS) id 15.1.312.18; Mon, 2 Nov 2015 14:13:58 +0000 Received: from DB3PR07MB138.eurprd07.prod.outlook.com ([169.254.16.135]) by DB3PR07MB138.eurprd07.prod.outlook.com ([169.254.16.135]) with mapi id 15.01.0312.014; Mon, 2 Nov 2015 14:13:58 +0000 From: Josh Howlett To: "saag@ietf.org" Thread-Topic: [saag] Need a public key authentication for SMTP etc. Thread-Index: AQHREyzLFHhDoEdieUugjKtNxqnGnJ6EOKmAgAAXXoCAABSjgIAEZHNQ Date: Mon, 2 Nov 2015 14:13:58 +0000 Message-ID: References: <33E77BAC-599E-402F-9470-5359465C5288@deployingradius.com> <20151030190223.GG18315@mournblade.imrryr.org> In-Reply-To: <20151030190223.GG18315@mournblade.imrryr.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.181.29.16] x-microsoft-exchange-diagnostics: 1; DB3PR07MB139; 5:tF8tIK+FR2Qx0FsySATOVwuuFtd5ctbTpPpEKBxMy8szvYO0UwCttGr8EhDkF1ZVFwyAimJX4XfI/hv8d70TObF5J6qheHcv78h1XaS8lJjGN8ILwkdctyLY+944p6+lZqe5yRYiKOmR8jLst2ioHg==; 24:Fc03LD1L8jn7shZEj3hIbi9zDcQI7ltaQcwHqA83Lvml4C9tPxjlqs8TrClytt60E/hRlwOYrMIdRfb9JzFqrZj7n1M4/V3XBcBjZFeaJy4=; 20:JG9MspZfIn5svgyh+Im6NhQ45Xn9eje3JnJWzrS1lWJYvpcwa4qdQ2iJf4+1ZLTiorDAghlCywkXaM1ZAW06uBpSs6NaR1OqWHzMaMoyg3lFb7mFm6SASfO5JnI3L1EmVHSvrM+c9RG/7KtFnwk88HIoGzW6wYCBUxU83C2NQcg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB139; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:DB3PR07MB139; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB139; x-forefront-prvs: 0748FF9A04 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(50986999)(5002640100001)(102836002)(54356999)(81156007)(2950100001)(33656002)(19580395003)(92566002)(97736004)(87936001)(76176999)(101416001)(2900100001)(74316001)(5004730100002)(93886004)(5007970100001)(5003600100002)(107886002)(5008740100001)(122556002)(189998001)(86362001)(105586002)(15975445007)(551544002)(106356001)(5001960100002)(2351001)(10400500002)(450100001)(2501003)(40100003)(74482002)(558084003)(11100500001)(66066001)(110136002)(76576001)(106116001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB139; H:DB3PR07MB138.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2015 14:13:58.3453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB139 X-MC-Unique: OMBqUxIWRr6EzXwJkXXwQg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Need a public key authentication for SMTP etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 14:14:09 -0000 > SASL also hash "EXTERNAL" and GSSAPI is not password based. > Specifically with GS2 you can expose your new underlying mechanism as par= t > of the negotiation: >=20 > https://tools.ietf.org/html/rfc5801 Yes -- We use EAP and SASL through GS2 as you describe; works fine. Josh. Jisc is a registered charity (number 1149740) and a company limited by guar= antee which is registered in England under Company No. 5747339, VAT No. GB = 197 0632 86. Jisc=E2=80=99s registered office is: One Castlepark, Tower Hil= l, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limit= ed by guarantee which is registered in England under company number 2881024= , VAT number GB 197 0632 86. The registered office is: One Castle Park, Tow= er Hill, Bristol BS2 0JA. T 0203 697 5800. =20 From nobody Mon Nov 2 18:36:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277F61B2B6D for ; Mon, 2 Nov 2015 18:36:45 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d__WsJb2S0Wm for ; Mon, 2 Nov 2015 18:36:44 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFCB71ACE3F for ; Mon, 2 Nov 2015 18:36:43 -0800 (PST) Received: by wmec75 with SMTP id c75so75431134wme.1 for ; Mon, 02 Nov 2015 18:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=15Wf1WgqCJZhFAat9pGDo40Zf8IJgUaQkyK8NXiliQU=; b=dPAjGcpxss4bY7cO5zfN096eK+NQHlWbfHKwFfgFxVprCLXTMmCwv6pRqNo0/2Kduz TJ8/c8goJVk+eo83VzvGR44VLfLO8k/p73d78Yp+9xPMNUtpKfthFdoewGP8M3PBnAoW LktNmyjSzF+HB7+C6K30K/PBeOHVQiirWPojC4IK7HlaC8J4Ts/lk6aNgeOtZtZtD+IY lj0jIAfX9fJjkfHM0q0zFN8KTqgNzqDOLA1Kz1ucHfukdO/vwQuEJb669djp+v+DGzAo yGV0bI2SD1HNYuX92sKBDQGtWOltOQreurLcPqoz/oWn2q35mqIcnSXmjJClJ7p6peRo PBHw== MIME-Version: 1.0 X-Received: by 10.28.132.13 with SMTP id g13mr17096087wmd.71.1446518202304; Mon, 02 Nov 2015 18:36:42 -0800 (PST) Received: by 10.28.214.142 with HTTP; Mon, 2 Nov 2015 18:36:42 -0800 (PST) Date: Mon, 2 Nov 2015 21:36:42 -0500 Message-ID: From: Kathleen Moriarty To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] CARIS draft report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 02:36:45 -0000 Hello, A draft summarizing the Coordinating Attack Response at Internet Scale (CARIS) has been published. Feedback is welcome as is taking on next step items: https://tools.ietf.org/html/draft-moriarty-carisreport-01 Thank you! -- Best regards, Kathleen From nobody Mon Nov 2 19:11:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F691AD1DB for ; Mon, 2 Nov 2015 19:11:06 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pyk9SALL4jk for ; Mon, 2 Nov 2015 19:11:05 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 3AAF21AD0CE for ; Mon, 2 Nov 2015 19:11:05 -0800 (PST) Received: by pabfh17 with SMTP id fh17so4963422pab.0 for ; Mon, 02 Nov 2015 19:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=7TQ/VTLB6t7tk/Ae1xE5EY7pCYN9Az8NvqI+eEhcsgI=; b=TJGe5umHeEvY8TCuKPwEhU77j1mjxZjq8VjsMl14roI3+3GxcBTVHr9g8T0zIg8l2L dDZy9Z6L/y8TCr/iNd2QUjysnxS/c0ACioznSNm0/C0HpnZ81q/mdUXMqEXYXY4NZJRc 7Fnkhb13RQsHU9YbnW0JRPkZ2YRGKpNOHHQI4wEtXjD/84/c8QbHNCvFLNPrXAaNRSyg OryLAyxvz3AA0KDxACdRRd53UcQxB79JCqGHBsOXnOtiaEru8I01fmbFdKq+gs1Df3FM IPg/mVuso0bfSO7EQbq3s+rXd/QSemsn1DvzWqcBHtYEsQv0RuSadpMnwPaS297TA4Ep Ul/A== X-Received: by 10.68.225.199 with SMTP id rm7mr31413484pbc.0.1446520264910; Mon, 02 Nov 2015 19:11:04 -0800 (PST) Received: from ?IPv6:2001:c40::3080:f541:be6b:b380:bce5? (t20010c4000003080f541be6bb380bce5.v6.meeting.ietf94.jp. [2001:c40:0:3080:f541:be6b:b380:bce5]) by smtp.gmail.com with ESMTPSA id bh4sm6340346pbb.17.2015.11.02.19.11.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 19:11:03 -0800 (PST) To: saag@ietf.org From: Melinda Shore Message-ID: <563825C5.1000200@gmail.com> Date: Tue, 3 Nov 2015 12:11:01 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] trans report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 03:11:06 -0000 The trans working group met Monday afternoon. We've got two new deliverables since IETF 93, a gossip protocol and a threat analysis, and the milestone for the core protocol document has been moved back to December 2015. There appears to be considerable support for taking on a document describing logging for binary artifacts (software distributions, for example). There is also interest in doing something with dnssec but there isn't agreement on a use case or on what would be logged, so discussions are continuing, with a side meeting to discuss it being held on Thursday at 3pm. Melinda From nobody Mon Nov 2 20:19:29 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A2B1B2D09 for ; Mon, 2 Nov 2015 20:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hntg7GgoA00y for ; Mon, 2 Nov 2015 20:19:24 -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 EFEBF1B2D0B for ; Mon, 2 Nov 2015 20:19:20 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id tA34JJ9k007739 for ; Tue, 3 Nov 2015 13:19:19 +0900 (JST) Received: from TakeVaioVJP13 (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id tA34JILC007730 for ; Tue, 3 Nov 2015 13:19:19 +0900 (JST) From: "Takeshi Takahashi" To: Date: Tue, 3 Nov 2015 13:19:21 +0900 Message-ID: <003701d115ee$d1f96fc0$75ec4f40$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdEV2IG27gc9sq4QRse4st34RkZglA== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Subject: [saag] MILE report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:19:25 -0000 MILE met at IETF 94 at 13:00 on Monday. There were about 40 attendees in the room and Jabber. We discussed five working group drafts. Indeed, IODEF-bis is currently under WGLC and is soliciting feedbacks. The prototype implementation of ROLIE draft was demonstrated to confirm the feasibility of the proposed technique. Moreover, two topics that relate to our activity are also presented. They are "using XMPP to transport IODEF" and "JSON mapping of IODEF", both of which are appreciated. To cover these topics, we will consider rechartering. From nobody Mon Nov 2 20:50:04 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B61B2DE1 for ; Mon, 2 Nov 2015 20:49:56 -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, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAR4Boc_oQzr for ; Mon, 2 Nov 2015 20:49:51 -0800 (PST) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 280C11B2DDF for ; Mon, 2 Nov 2015 20:49:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1446526182; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=Be6cAMvfC4o+kkLJpDaS6htTeiMQIksSe5mih4JMwiM=; b=HbxrmGKNJ/+Uc9eOXxGO5u5ceGTickMUJCp1fqxC2dhrB/2RC7/bxOZ+u0naLpxHPBUpAIwp2QtHn7lGatQzWBvZs3YAyP5r/L2IhsK2zbmzxesoyiLm/Rz0e2mKr455ct9+MkvjE8ckUgEdK/mrcFtjCYs6Maq4xqS5MwdKi94= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R461e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03285; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; Received: from 10.22.58.194(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Tue, 03 Nov 2015 12:49:36 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 03 Nov 2015 12:49:28 +0800 From: "Kepeng Li" To: Message-ID: Thread-Topic: ACE report Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: Subject: [saag] ACE report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:49:56 -0000 ACE met at IETF 94 at 9:00 on Monday. There were about 100 attendees in the room and Jabber. We discussed architecture draft and various solutions. For the architecture draft (Actors), we found several volunteers to review the draft and plan to initiate WGLC in Dec, 2015. For the solution drafts, we have DCAF solution and Oauth Profiling solution presented in the meeting. The decision in the room was to accept the OAuth profiling draft as a starting point for future work of the solution charter item. Kind Regards Kepeng From nobody Mon Nov 2 20:57:38 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6F1B2DBD for ; Mon, 2 Nov 2015 20:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1kgiuiSYQua for ; Mon, 2 Nov 2015 20:57:36 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [217.34.220.150]) by ietfa.amsl.com (Postfix) with ESMTP id 813A51A1BCF for ; Mon, 2 Nov 2015 20:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1446526651; d=isode.com; s=selector; i=@isode.com; bh=eKxQGJT2a+F/qzJ2xbBWiQ4Q1M+OXHtVYn8t6V6xTVo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=U8CSEg8ni9fFniZ4VTKc5ifiNpNOnIPqTYrlN1Beyh6RWSAEHW89qpk99Z9Qv+jZFwrQow itF8Cgitdbl1yDssiU/CaoCiFqevuTun/4B3S7rrfDYQSKqrn8GI5piH30RfKu1EyIUEzf 6t836Uhega+vBJhjM9BhU5WzIhOXDu8=; Received: from [133.93.32.122] (dhcp-32-122.meeting.ietf94.jp [133.93.32.122]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 3 Nov 2015 04:57:29 +0000 To: "saag@ietf.org" From: Alexey Melnikov X-Enigmail-Draft-Status: N1110 Message-ID: <56383EA4.4070407@isode.com> Date: Tue, 3 Nov 2015 13:57:08 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Archived-At: Subject: [saag] CFRG meeting report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:57:37 -0000 CFRG IRTF Research Group met on Monday. Short status of RG documents was presented, the most important being: 1) Elliptic Curves for Security (draft-irtf-cfrg-curves-11) is in RFC Editor's queue. 2) Edwards-curve Digital Signature Algorithm (draft-irtf-cfrg-eddsa-00) needs to specify KDF and pre-hash functions for ed448, but otherwise it is heading in the right direction. Definition of ed25519 is stable at this point. There was one presentation on "FSU: Identity-based Authenticated Key Exchange". The rest of the meeting was spent discussing which topics CFRG should work on next after finishing currently outstanding EC work. We finished 30 minutes early. From nobody Mon Nov 2 21:05:22 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA471B2E4B for ; Mon, 2 Nov 2015 21:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFZ7UYN9QD-r for ; Mon, 2 Nov 2015 21:05:19 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1C01B2E46 for ; Mon, 2 Nov 2015 21:05:19 -0800 (PST) Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0366.namprd09.prod.outlook.com (10.160.247.20) with Microsoft SMTP Server (TLS) id 15.1.312.18; Tue, 3 Nov 2015 05:05:18 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0312.014; Tue, 3 Nov 2015 05:05:18 +0000 From: "Waltermire, David A." To: "saag@ietf.org" Thread-Topic: IPsecME Report Thread-Index: AQHRFfU753UAIjbTHEOx9WJ8+cbAuw== Date: Tue, 3 Nov 2015 05:05:17 +0000 Message-ID: <1p5tockj3weuylog59ighf5e.1446527113681@email.android.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=david.waltermire@nist.gov; x-originating-ip: [2001:c40:0:3024:e8db:6b8b:ab70:fbd9] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0366; 5:/b1IHZib5Q+k8KvDugHEKeOiJuV6LgyJy/12ksyfQcMsXC+tiTm3L4aWlioccVQhAz8M3pvOMpPvmZbiNWJnk7dASefqZ8dSIagC5mkDcZSIta/E6nNb+4+XRv/6HnFMs5k10ntp/yRUHh9iX63Dnw==; 24:q8GGtrDK5aFxFujDKO87zgJ5hmXZz663HJFcjmQ41wHu/pVdXZ3GsU82Pv0LCwHyVKbbsS0jrcFy/1yRzznQEHMtQtYtwCJow6vhAU+O1VA=; 20:OkzETj5KQcqI/Wx+olKHI40H/Qvp7Mp2mVwn4Sp0WBvwVTcpy3ZjoxhgiKTTHxGLxWKbh1bb9qVz47SNJkh2Sw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0366; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:DM2PR09MB0366; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0366; x-forefront-prvs: 0749DC2CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(92566002)(86362001)(97736004)(450100001)(2501003)(122556002)(221733001)(87936001)(5002640100001)(81156007)(40100003)(101416001)(229853001)(106356001)(102836002)(2900100001)(189998001)(2351001)(33646002)(105586002)(5007970100001)(63666004)(5004730100002)(77096005)(110136002)(95246002)(99286002)(5008740100001)(5001960100002)(11100500001)(50986999)(107886002)(10400500002)(106116001)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0366; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <21542879930A534AB37B47569E16E686@nistgov.onmicrosoft.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2015 05:05:17.6876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0366 Archived-At: Subject: [saag] IPsecME Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:05:21 -0000 CklQc2VjTUUgZGlkIG5vdCBtZWV0IGF0IElFVEYgOTQuCgpXZSBhcmUgc3RhcnRpbmcgd29yayBv biB1cGRhdGluZyByZmM0MzA3IHRvIGFkZHJlc3MgbmV3ZXIgYWxnb3JpdGhtIHJlcXVpcmVtZW50 cy4gVGhlIFdHIGlzIGN1cnJlbnRseSBoYXNpbmcgb3V0IHdoYXQgc2hvdWxkIGJlIHVwZGF0ZWQu CgpEaXNjdXNzaW9uIG9uIGRyYWZ0LWlldGYtaXBzZWNtZS1kZG9zLXByb3RlY3Rpb24gaGFzIGJl ZW4gcXVpZXQuIFdlIGFyZSBwbGFubmluZyB0byBiZWdpbiB0byBkcml2ZSB0aGlzIGRyYWZ0IHRv d2FyZHMgV0dMQyBpbiB0aGUgbmVhciBmdXR1cmUuCgpXZSBhcmUgcGxhbm5pbmcgdG8gaG9sZCBh IHZpcnR1YWwgaW50ZXJpbSB0byBtYWtlIHByb2dyZXNzIG9uIHRoZSBjdXJyZW50IFdHIGRyYWZ0 cyBiZWZvcmUgSUVURiA5NS4KCg== From nobody Mon Nov 2 21:12:16 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF9E1B2E89 for ; Mon, 2 Nov 2015 21:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOBEWx_yChEb for ; Mon, 2 Nov 2015 21:12:10 -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 F2C771B2E7C for ; Mon, 2 Nov 2015 21:11:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C1845BE53 for ; Tue, 3 Nov 2015 05:11:34 +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 cb63v1V8jYeQ for ; Tue, 3 Nov 2015 05:11:32 +0000 (GMT) Received: from [133.93.24.87] (unknown [133.93.24.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 590F7BE51 for ; Tue, 3 Nov 2015 05:11:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446527492; bh=ZnhqXOG0sdxjBBWYAS7L/VGoYsCpStlwBrmiLlY7w+Q=; h=Subject:References:To:From:Date:In-Reply-To:From; b=q/DHGI6w7/dB5RyzKO0JAF4gXJUggmXWeNzwEpKSurfNGtm8vYioihB/m1Pbri71N knYr048x01dCvoY4tst9+Dl9vC4f6IwmiIi+HCUXNUDIMJsnT8NlOqfofrJdzoZ4dU MmstTDLN/DLB4XM0Ty6PWEuRBgUwlshs/Zv1IQqg= References: To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: <56384201.1020605@cs.tcd.ie> Date: Tue, 3 Nov 2015 05:11:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] Fwd: ICANN's RDAP Implementation Profile Proposal X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 05:12:12 -0000 Hiya, Please see below and go along if you're at the IETF, interested and available. The presentation mentioned below was large but I think is also at [1]. Cheers, S. [1] https://meetings.icann.org/en/dublin54/schedule/wed-rdap-implementation/presentation-rdap-implementation-21oct15-en -------- Forwarded Message -------- Subject: ICANN's RDAP Implementation Profile Proposal Date: Tue, 3 Nov 2015 04:24:25 +0000 From: Teague, Nik To: Kathleen Moriarty , stephen.farrell@cs.tcd.ie Kathleen, Stephen hi, There’s an meeting in room 419 tomorrow at the ietf location from 9am to 12 which pertains to the rdap migration from whois profile as per icann. I’ve attached the relevant slide deck from the recent meeting in Dublin. This may be interesting to individuals concerned with data privacy as I think there may be some open questions. I didn’t want to randomly post directly to SAAG but thought you may want to look over it. Thanks, -Nik From nobody Tue Nov 3 14:47:54 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2221B3414 for ; Tue, 3 Nov 2015 14:47:52 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyvfVPRHT7xn for ; Tue, 3 Nov 2015 14:47:51 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 D68901B3563 for ; Tue, 3 Nov 2015 14:47:29 -0800 (PST) Received: by pacdm15 with SMTP id dm15so6769845pac.3 for ; Tue, 03 Nov 2015 14:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:to:mime-version; bh=14KruXrZwieEfQhSrbAULN+HmvSeDPN73xA14S2l26Q=; b=qbqlJBQZxzxPFPHTJ8fuG/lRl5AklNtTNMXxXJUjs7uBKwkhQwpc+FDE3rn1kidLUx P9CSnpap0iQQn2H2dOBxgQaUV6rgKcc2nuFxgrYWZB/vwJHte0113XIJ4cD+gp/nE9T3 PNHIL1qZY/YeejvCIWqEQPffRMPBa3BFqE+gbKekjuO3ewo+PoP9t0n0gH4EJVI0V3hp 9PGKZ9nSyXP6iFSc02ni2jTacXub0rCyNtI3iQR07Y7SwfDEcP3MCiVDyCSImx+HyIUk j37GxhIRNOs1KLgjtiYOM/r5PuibV68c7T3tCL3tuQt3ZxEXEl2x9Uv4sndtdQICecEG LTqQ== X-Received: by 10.69.16.228 with SMTP id fz4mr37019825pbd.164.1446590849500; Tue, 03 Nov 2015 14:47:29 -0800 (PST) Received: from [172.16.202.34] (p4197-ipngn3901hodogaya.kanagawa.ocn.ne.jp. [153.215.99.197]) by smtp.gmail.com with ESMTPSA id ph8sm31436558pbc.8.2015.11.03.14.47.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 14:47:28 -0800 (PST) From: Adam Montville X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_DF470E18-C4C3-4F65-AC47-369280DAE673"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 4 Nov 2015 07:47:26 +0900 Message-Id: <2F02DD2C-B201-453A-A3A3-953BE805DA16@gmail.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [saag] SACM Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 22:47:53 -0000 --Apple-Mail=_DF470E18-C4C3-4F65-AC47-369280DAE673 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii SACM Met on Tuesday (and will meet again on Thursday). There were about 50 people in attendance and/or in Jabber. We reviewed = our Requirements, Architecture, and Information Model draft status. Work action between now and Thursday is to make progress on the one = remaining open issue for Requirements so that it may progress to WGLC, = where we expect potential additional feedback. We'll be meeting again on Thursday to review solutions draft = submissions, see what work could be done between sessions, and consider = an additional data model construct. We expect to plan for two virtual interims between 94 and 95. --Apple-Mail=_DF470E18-C4C3-4F65-AC47-369280DAE673 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWOTl+AAoJEDEhyx7etgAB88cQAMJDsElOEhwgYQ/G4VUYYLHQ 1pIauekoXNq/ObbO4ghlWx7KVGqIRLNUvSCMAm6JkP95oSLzTQTbJGJmDP89sMy+ fzAv5pqPiYNIveISFxAnJuFgiFAZFLG5iqwPOu5+bazuboHBTRyT3fXFnIk7ZeI3 q0Vsc1B5t6jaH2OOxQ9w+Q3B7NMnSl91YQbLS3wBn7VDiwhoLvoLzuuU+BDEtrIj PBhycORaVbs94/ZHmgf+vpmAfxAo0eKCfQPGftc940Fb81oYw0iD5vxRGnAzEYLE WsNYJc8F0cUjz9gp4rft/eJ5xe7xZnblNF8CmcHcFw2FPsYzDLZ8X22WcSmygLgM uHtwDDjy10qjiHoei/ETp76+OwjdgSB64FeqsrA+8zHbSdNkg4h6CisPcrz1GBMK e0VyAOkm0babD9lagq03Drev6d5eJxl3Tucp30V/qYJQvQMPlASbstIK7ni+RPqY uoQUtKqFjKaHCPjlFbJ3YFb/E782A6kox8B7M+kpnMqisvjLsnWG3IU+OpM/vFVX VIh6vBe/A8mHadt+zGadpQ5otExjJq5/e4W00QIfv4/OXO4csRr6z9YoH+M7e9bZ CkGPT8tROXWt52afK0EYBeizrRM7sCKJ7Uvz5/vwtJLKnN5qoNXWOPP/vBiGH1Kd RvC0iug5bF4M091JBXyc =u2Lf -----END PGP SIGNATURE----- --Apple-Mail=_DF470E18-C4C3-4F65-AC47-369280DAE673-- From nobody Tue Nov 3 17:35:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC761B2F95 for ; Tue, 3 Nov 2015 00:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PN17NoL6WoW6 for ; Tue, 3 Nov 2015 00:38:52 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675E61B2F78 for ; Tue, 3 Nov 2015 00:38:52 -0800 (PST) X-AuditID: 1209190d-f79766d000002fec-66-5638729b2792 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 05.F6.12268.B9278365; Tue, 3 Nov 2015 03:38:51 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tA38cobg014028; Tue, 3 Nov 2015 03:38:50 -0500 Received: from dhcp-29-147.meeting.ietf94.jp (dhcp-29-147.meeting.ietf94.jp [133.93.29.147]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA38cjDF007136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2015 03:38:48 -0500 From: Justin Richer Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2015 17:38:44 +0900 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixG6nrju7yCLMYEKDoMXl+UUWU/o7mRyY PCa+/cjisWTJT6YApigum5TUnMyy1CJ9uwSujOnfW1kLVrBX3Ptt1sD4krWLkZNDQsBEYnn3 ZCYIW0ziwr31bF2MXBxCAouZJH7O/sYM4WxglDi48gpU5gaTxJbPi1hAWtgEVCXmr7wF1s4s oC7xZ94lZghbW2LZwtdgtrCAiMT/O2+BbA4OFgEViambYkFMXgEriS3PXSCqtSRW/GkCqxYR EJR40DcJbDqvgJ7Eq1uXoQ6Vldj9+xHTBEb+WUiWzUKybBaSlgWMzKsYZVNyq3RzEzNzilOT dYuTE/PyUot0jfRyM0v0UlNKNzGCQpFTkncH47uDSocYBTgYlXh4FywxDxNiTSwrrsw9xCjJ waQkysuRbxEmxJeUn1KZkVicEV9UmpNafIhRgoNZSYS3IBAox5uSWFmVWpQPk5LmYFES5930 gy9ESCA9sSQ1OzW1ILUIJivDwaEkwWtXCNQoWJSanlqRlplTgpBm4uAEGc4DNNwTpIa3uCAx tzgzHSJ/ilGXY8GP22uZhFjy8vNSpcR5HUCKBECKMkrz4OaAUkhrrOzkV4ziQG8J85aAVPEA 0w/cpFdAS5iAloRvMwVZUpKIkJJqYJSacGkfX4jJtfvH/j/6cY8vc77ESqfvGgpMAVt9DolN 5fVcEC5csYSfdXfrTfVvx3PPLbuc6HN1wkXP13/XbxCQ1d2gHyMYsPeZl9vJnG1BL2pbfu1L 9QkSC2Za8rP82tZ6n7vhQTburMFV2bPKalQmSZq//z73qtWzl0usP9tVqHxPei+QZqjEUpyR aKjFXFScCAALfhtP/AIAAA== Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:35:56 -0800 Subject: [saag] COSE Status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 08:38:54 -0000 COSE met on Tuesday afternoon. We had a short presentation on newly proposed COSE Token work that has = been raised in the ACE working group, to parallel JWT from JOSE. There = was general support for doing the work, but it=E2=80=99s an open = question on where it should happen (COSE, OAuth, and ACE are all = candidate WG=E2=80=99s, each would require rechartering). We had a presentation from the ACE working group that contained proposed = optimizations to the COSE spec. We reviewed the current state of the COSE specification and walked = through open issues. Each issue was given a definitive action from = either the editor or to start a list thread. The chairs will call consensus on the following issues: 1) Placement of CDDL within the document 2) Specification of RSA 1.5 mechanisms 3) Specification of RSA PSS algorithms and keys 4) Adoption of the COSE Token =E2=80=94 Justin & Kepeng= From nobody Tue Nov 3 17:36:01 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EECB1A878A for ; Tue, 3 Nov 2015 17:03:43 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xvsdkjw0QoWX for ; Tue, 3 Nov 2015 17:03:40 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 D0AAB1A8779 for ; Tue, 3 Nov 2015 17:03:40 -0800 (PST) Received: by padhx2 with SMTP id hx2so26555950pad.1 for ; Tue, 03 Nov 2015 17:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=n+77i85mC7n3cB0zvqDbwb3WUNYazAcNnYgvh/yI5n0=; b=cGF/e7Z7o1d7hfE/sqhXH8dYrSWQGyH18fqyQXgj+GEsTw631KnI8u2hTRfFW4DQ15 mfpuFwWEurUMdIY81FQ4E3uqzWuYlVW3eXuafOgh1wOtHQnlZeyxXrLlYnmD94F599QM zsl4RHgUzHBAEanikHzMok0gU9WovytJrxoM+eU3SWvZh6ji+C7TKFpp2f6ZKZBEEGdI ECaMpOa4FuhI4q6ugfkYSNsP7PIJDPUprmpzrVYwPtQG8hEw3gHd3qZb3cMeXHgRUejM ASNFZD7F0MtGbrbcTc6axntui7iyPxYhRU0OOag9xpmw+63eNToEOqrVkMINizP4fERw 1WbA== X-Received: by 10.66.172.6 with SMTP id ay6mr37371387pac.44.1446599020519; Tue, 03 Nov 2015 17:03:40 -0800 (PST) Received: from dhcp-24-227.meeting.ietf94.jp ([133.93.24.227]) by smtp.gmail.com with ESMTPSA id nu5sm31693243pbb.65.2015.11.03.17.03.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 17:03:40 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <8C7BDC9C-3F3C-4962-B841-0D336A9C45BA@gmail.com> Date: Tue, 3 Nov 2015 20:03:36 -0500 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:35:56 -0800 Subject: [saag] Keychain implementation issues X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:03:43 -0000 (The note sent to SAAG on October 27th about KeyChain YANG vs KeyTable YANG brought the topic of this email to the front of my mind.)=20 I was at Cisco when the original KeyChain implementation was undertaken by PST. I believe that the original Cisco (Classic) IOS KeyChain implementation for routing protocol=20 authentication, IGNORED the KeyID (or equivalent) field=20 and simply tried all of the keys present, accepting the=20 received packet as valid once any key passed the mathematical=20 validation checks. I understand that implementation strategy also was used by other KeyChain implementations at a range of different firms. A result of this implementation choice is to multiply the adversary=E2=80=99s effectiveness for a =E2=80=9Cblind" DDOS attack on a=20= router=E2=80=99s CPU by the number of keys present for a given=20 routing protocol. (ASIDE: I have reason to believe that such blind DDOS attacks on routing protocols have been seen on the deployed Internet,=20 so posting this note does not increase operational risk.) A better implementation approach would be to ALWAYS use the KeyID field (or equivalent, depending upon the protocol) and other Security Association selection parameters=20 to select a SINGLE key to use in attempting the mathematics=20 to validate a received routing protocol packet. That reduces such attacks to at-most 1 expensive computation=20 per received routing protocol packet. Also, except in the event of a key management fault [e.g., see discussion in RFC-4822, Section 5.1 (2)], any expired keys ought not be used to attempt to validate a received routing protocol packet. These issues are somewhat orthogonal to the question of how one ought to structure a YANG module for routing protocol authentication information, but one certainly hopes that deployed implementations of the KeyChain method either have been or soon will be updated to ONLY check a key if the KeyID value for that key, and the Routing Protocol value for that key, and any other Security Association selection criteria=20 match the received routing protocol packet. Yours, Ran From nobody Tue Nov 3 17:36:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAD21A8877 for ; Tue, 3 Nov 2015 17:30:32 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX8C5zIfJgKZ for ; Tue, 3 Nov 2015 17:30:27 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 9029E1A887B for ; Tue, 3 Nov 2015 17:30:27 -0800 (PST) Received: by pacdm15 with SMTP id dm15so10855237pac.3 for ; Tue, 03 Nov 2015 17:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=8ngb7Pie7fDt7RA9DyWiQa3sZ15wdjNLMntu5318HQA=; b=kCyCwsUd275zLJijEn1Hs9im1M150vvD/WCCLjC7bekNYDCZBj5qQqHZg+8iG/FQnX K7XSOY/w39HC5raBT0487zI4vYFqMZTXppJ9aXxKmm1XHOlH3p+HbbKAgwiZV73FGV8E JPcEgzF/dC0u80mE2lbiNSQOgbHVpOGNN+aRgQa2tayQarJLhWbcCSWrrLTdMlrL2a44 YKJS6gPipYhYrTYyPh8GMaP0dCAVzjeN3r/dguBJ27JpIiVRBPE3n1tWdPHZ8ggGZHF+ 3ddrsUb1ZJl+XvYhHNoTchC5CW50iStkeQ/c4Zc9Tv4j5ubzxsJAVLl5Jd0XO4AiktvY pmmw== X-Received: by 10.68.249.164 with SMTP id yv4mr33095276pbc.51.1446600627132; Tue, 03 Nov 2015 17:30:27 -0800 (PST) Received: from dhcp-24-227.meeting.ietf94.jp ([133.93.24.227]) by smtp.gmail.com with ESMTPSA id xe9sm31830048pbc.4.2015.11.03.17.30.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Nov 2015 17:30:26 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7E130E2B-4575-4F47-8DA8-A2DBC3C08945@gmail.com> Date: Tue, 3 Nov 2015 20:30:24 -0500 To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 17:35:56 -0800 Subject: Re: [saag] advice on key table YANG module X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:30:32 -0000 I have reviewed both the KeyTable YANG Module and the KeyChain YANG module. =20 I have been involved in IGP routing protocol authentication since=20 the mid/late-1990s, including being one of the designers of OSPFv2=20 Authentication (The text in RFC-2328, Appendix D.3 is why I=E2=80=99m = mentioned=20 as a contributor in that RFC). I have both built routers/switches and worked in network engineering at a multi-continent ISP. 1. KeyTable YANG Module The KeyTable YANG module is fully aligned with and meets all of the functional requirements for Security Associations for current IETF routing protocol authentication specifications (e.g. RIPv2, OSPFv2, OSPFv3, BGP). The KeyTable RFC was designed by security folks who understand the concept of Security Associations. It could be implemented=20 in several different ways in a particular system (e.g. router). The KeyTable YANG module appears to meet all the functional needs. 2. KeyChain YANG Module In principle, a corrected version of the KeyChain YANG module could meet those functional requirements. However, the current=20 KeyChain YANG module (-09) appears NOT to meet those requirements. Also, the current KeyChain YANG module (-09) [page 5 bottom and page 6 top =E2=80=9Csend-and-accept-lifetime"] appears NOT to fully = support=20 Smooth Key Rollover. =20 For example, smooth key rollover CANNOT -reliably- occur if the=20 =E2=80=9Caccept lifetime (start time, end time)=E2=80=9D is identical to = the=20 =E2=80=9Csend lifetime (start time, end time)=E2=80=9D. Of course, one = can get lucky. I=E2=80=99d prefer that we design for reliability, rather than hope for luck. OSPFv2 Cryptographic Authentication (e.g., RFC-2328, Appendix D.3)=20 specifies different send lifetimes and accept lifetimes because an objective was to support Smooth Key Rollover. The KeyChain YANG model (-09) does additionally have the concept of distinct send lifetime and accept lifetime, but it is optional, and specified later, with NO discussion of why separate lifetimes for these functions is critical operationally if one wants Smooth Key Rollover. This module does NOT appear to meet all the functional needs at present. So it needs to be reworked to fully support Smooth=20 Key Rollover before it ought to be considered for advancement. 3. Non-relationship of CLI to YANG There seems to be a very widespread mis-apprehension within the routing protocol YANG community that the YANG ought to follow the human command-line-interface (CLI). In fact, small operators often still manually configure their routers/switches/other devices, in which case both NetConf and YANG are likely not very relevant. Larger operators (e.g. Tier-1 ISPs) generally have automated device provisioning/configuration systems driven by software tool chains. A common pre-NetCOnf implementation would have combination of Expect, Tcl, Perl, & Python scripts connected to a back-end network configuration database, and executed=20 periodically via a cron job (or equivalent). A former employer of mine had such a system deployed operationally over 15 years ago. =20 For this larger operator situation, there is not a particular=20 advantage to closely modeling the YANG XML upon any particular CLI. =20 In fact, a fresh start with a clean-sheet-of-paper design might well (IMHO, very probably would) be advantageous for the coders building=20 and maintaining these automated configuration/provisioning management=20 systems. Summary: - Smooth Key Rollover is a critical operational capability. - KeyTable YANG module is ready now because it meets all=20 functional requirements. - KeyChain YANG module needs to be reworked before it can meet all functional requirements. For example, at present it does not fully meet functional requirements to reliably achieve Smooth Key Rollover. Yours, Ran From nobody Tue Nov 3 17:42:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138131A889D for ; Tue, 3 Nov 2015 17:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnMzIFsYYMyR for ; Tue, 3 Nov 2015 17:42:16 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22061A21B3 for ; Tue, 3 Nov 2015 17:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=291; q=dns/txt; s=iport; t=1446601337; x=1447810937; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uNd8TAczBf1W9I+px/sgjdZuRyaj4GAsAENlLU+gK2Q=; b=AlUNUMn70+8l02hjeDJcl4janKmUMYPhsCyF0RL6l3aaZ1fZBBArk8UE 1a9GJgsqC9SHDqofwn+JpBpmg4QmUOiOEgrheWbZNzXeO62xl/mKfaElg UZykZxsCkUUy4DPY5FsWGHareHZeg+taGAQGcwa9bBBK3bctiwFYpw+4f s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQCTYTlW/5FdJa1VCYM7gUi9QAENgV2HUjgUAQEBAQEBAX8LhDw6UQE+Qg8QCASIQaEAoG0BAQEBBgEBAQEBAQEchlWCEIcfg3OBFAWWRgGNIZw+AR8BAUKCER2BVoUfgQcBAQE X-IronPort-AV: E=Sophos;i="5.20,240,1444694400"; d="scan'208";a="204649062" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 04 Nov 2015 01:42:16 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tA41gFPv031591 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Nov 2015 01:42:15 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 19:42:14 -0600 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 19:42:15 -0600 From: "Klaas Wierenga (kwiereng)" To: "saag@ietf.org" Thread-Topic: abfab status Thread-Index: AQHRFqII97pt8DFF1UChc+kBEpYQ0A== Date: Wed, 4 Nov 2015 01:42:15 +0000 Message-ID: <1678570C-890E-4E4A-9DC3-49FE76464DD1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.173.186] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C0C4380EA42C3408B0116C02E74704D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] abfab status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 01:42:17 -0000 Abfab did not meet at this IETF.=20 The AAA-SAML draft has passed last call and is in shepherd write-up. That l= eaves one outstanding deliverable, the UI considerations draft, to complete= the chartered items. Klaas -- Klaas Wierenga Identity Architect Cisco Cloud Services From nobody Tue Nov 3 18:10:18 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421C21A89A6 for ; Tue, 3 Nov 2015 18:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7gKnR52CJ6q for ; Tue, 3 Nov 2015 18:10:14 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460271A899B for ; Tue, 3 Nov 2015 18:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8638; q=dns/txt; s=iport; t=1446603014; x=1447812614; h=from:to:subject:date:message-id:mime-version; bh=9HFsYryxHQX+N+EyR8ERVLFNJjcFh+qrLSw18AGgLPw=; b=ExRGt7iPpm+1kOmc1opsdD5ooYD0Gw7M/sQhigrHMJMEULH5g2hOeWqQ RP0wGxWDDn6rgSA/TNNU1+Ws7u/tkLrt7ASFUD4YWwz+LqCHmVs9YRyrO P0I+RgCpewy30GpJtI6f7xzrmk3ENvD55grc1h+dKh2dbYLb52tsnC2YF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQDPaDlW/4MNJK1egm5NU3W9QAENgV0jhXCBPzgUAQEBAQEBAX8LhDyBCwGBAA8YBCyIFQ2gc6BtAQEBBwEBAQEbBIZWhiODBBEBTIQwBY1TiHMBe4QhiAWBWpISiFIBHwEBQoQEhGU6gQcBAQE X-IronPort-AV: E=Sophos; i="5.20,240,1444694400"; d="scan'208,217"; a="43703925" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2015 02:09:53 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tA429q75013350 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Nov 2015 02:09:52 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 21:09:51 -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.1104.000; Tue, 3 Nov 2015 21:09:45 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: Anima report Thread-Index: AQHRFqXgC8wr+esBakmn/J4/2T/ckA== Date: Wed, 4 Nov 2015 02:09:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.89.15.160] Content-Type: multipart/alternative; boundary="_000_D25EA7C8147A82ncamwingciscocom_" MIME-Version: 1.0 Archived-At: Subject: [saag] Anima report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 02:10:17 -0000 --_000_D25EA7C8147A82ncamwingciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANIMA met on Monday (1pm) and Tuesday (3pm). Below is a summary of the sessions (thanks to Max Pritikin for providing so= me of the summary content): Update reports were provided for the following drafts: - draft-ietf-anima-grasp (Anima Generic Signaling) - draft-ietf-anima-bootstrapping-keyinfra (Auto Bootstrapping status from = the Design team) - draft-ietf-anima-autonomic-control-plane (Control Plane and Addressing) - draft-behringer-anima-reference-model (Anima reference model) - draft-jiang-anima-prefix-management (Autonomic Prefix Management in Large-sc= ale Networks) - draft-eckert-anima-stable-connectivity (Using the Control Plane for stabl= e connections) - draft-liu-anima-grasp-distribution (Information Distribution over GRASP) - draft-behringer-anima-autonomic-addressing (Addressing in the ACP) - draft-du-anima-an-intent (Autonomic Network Intent concept and format) - draft-peloso-anima-autonomic-function & draft-ciavaglia-anima-coordination (A Day in the Life of an autonomic function= ) There is discussion about GRASP depending on ACP security model or providin= g some of its own (to run independently of ACP). * There is discussion of how to manage "adjacency table" state collected pr= ior to security being established. Clearly a possible attack avenue. * bootstrap key requirements touched on an important point but no further d= iscussion ensued: does bootstrapping depend on having a valid clock or not?= Anima may need to address time synchronization as part of bootstrapping bu= t has not been picked up as a requirement yet. * Update to ACP erquirements now explain why IPv6 (only) is sufficient; ACP= requirements strive for long term simplicity The group has accepted the Reference Model, Stable Connectivity and Prefix= Management as WG drafts. There was discussion on adoption of the Autonomi= c Addressing with general consensus to accept which will also be confirmed = on the email list. - Nancy --_000_D25EA7C8147A82ncamwingciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7F7420DAA11EC0409E09D2DD1A9F803D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
ANIMA met on Monday (1pm) = and Tuesday (3pm).

Below is a summary of the = sessions (thanks to Max Pritikin for providing some of the summary content)= :

Update reports were provid= ed for the following drafts:
 - draft-ietf-anima-grasp (Anima = Generic Signaling)
 - draft-ietf-anima-bootstrapp= ing-keyinfra (Auto Bootstrapping status from the Design team)
 - draft-ietf-anima-auto= nomic-control-plane (Control Plane and Addressing)
 - draft-behringer-anima-re= ference-model (Anima reference model)
 - draft-jiang-anima-prefix-= management (Autonomic Prefix Management in Large-scale Networks)
 - draft-eckert-anima-stab= le-connectivity (Using the Control Plane for stable connections)
 - draft-liu-anima-grasp-dis= tribution (Information Distribution over GRASP)
 - draft-behringer-ani= ma-autonomic-addressing (Addressing in the ACP)
 - draft-du-anima-an-intent (Au= tonomic Network Intent concept and format)
& draft-c= iavaglia-anima-coordination (A Day in the Life of an autonomic fun= ction)

There is discussion about GRASP depending on ACP security model or pro= viding some of its own (to run independently of ACP).

* There is discussion of how to manage “adjacency table" st= ate collected prior to security being established. Clearly a possible attac= k avenue. 

* bootstrap key requirements touched on an important point but no furt= her discussion ensued: does bootstrapping depend on having a valid clock or= not? Anima may need to address time synchronization as part of bootstrappi= ng but has not been picked up as a requirement yet. 

* Update to ACP erquirements now explain why IPv6 (only) is sufficient= ; ACP requirements strive for long term simplicity

The group has accepted the Reference Model,  Stable Connectivity = and Prefix Management as WG drafts.  There was discussion on adoption = of the Autonomic Addressing with general consensus to accept which will als= o be confirmed on the email list.

- Nanc= y
--_000_D25EA7C8147A82ncamwingciscocom_-- From nobody Tue Nov 3 20:42:49 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EEA1AC3CC for ; Tue, 3 Nov 2015 20:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfFgysa5liJn for ; Tue, 3 Nov 2015 20:42:45 -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 AC6B61AC3CB for ; Tue, 3 Nov 2015 20:42:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DDD82BE2F for ; Wed, 4 Nov 2015 04:42:43 +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 zfV8z6Hb-fru for ; Wed, 4 Nov 2015 04:42:42 +0000 (GMT) Received: from [133.93.24.87] (unknown [133.93.24.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ACF3FBDF9 for ; Wed, 4 Nov 2015 04:42:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446612162; bh=SXgmWzsKVwBoiIZr47c9tkzJu//o+Rbn2fd+zHlYWVA=; h=To:From:Subject:Date:From; b=i+VtYGPmFK+YGpw2Zk2q5Wn1XNdrQjtTogcsScGV4dWztbNUCsCAWmRRl69s6PmmO SzKiakI8dZdEVtxK21yHbUpOsCf1DXwP4jYUlEo1235cC9wqpbhj0hez3FxO4VQh0Z UZ9C9zO/Ti430koEba2UjSVwNqktO1qU2x6vXqyc= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56398CBD.9050109@cs.tcd.ie> Date: Wed, 4 Nov 2015 04:42:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:42:47 -0000 Hiya, At the secdir lunch this week in Yokohama we spoke about needing a bit of organisation around adding new curves and about deprecating some old algs (e.g. sha1). There's a scattered set of stuff that'll need doing some of which is in progress (e.g. drafts allocating OIDs for new curves so they can appear in certificates), others of which may not yet be. One possibility would be to try do this as a WG with a charter that tightly defines which new things can be added but allows for deprecating anything that should be deprecated. The putative WG here would not I think tackle items where we have a current WG active, e.g. TLS can handle defining codepoints for TLS. As a separate but related thing, Alexey said he'd create a cfrg wiki page where folks could add the names of drafts that are defining things related to new curves. That might feed into the positive parts of chartering. FWIW, if this is something people support and find useful, Kathleen and I are happy to help it happen. Next step would likely be to start a mailing list for this and see if there's enough energy to get stuff going. (If there is, I doubt a BoF would be needed.) Thoughts? S. From nobody Wed Nov 4 16:17:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20D81ACD93 for ; Wed, 4 Nov 2015 16:17:24 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F9gYIKgrlAM for ; Wed, 4 Nov 2015 16:17:23 -0800 (PST) Received: from plainfield.sei.cmu.edu (plainfield.sei.cmu.edu [192.58.107.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D241ACE27 for ; Wed, 4 Nov 2015 16:17:19 -0800 (PST) Received: from pawpaw.sei.cmu.edu (pawpaw.sei.cmu.edu [10.64.21.22]) by plainfield.sei.cmu.edu (8.14.4/8.14.4/1408) with ESMTP id tA50HI7m026070 for ; Wed, 4 Nov 2015 19:17:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1446682638; bh=G6HmuaVd7MVASlnuklJ0GPZtybfDK+klCDZG9PObkSI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version:Sender:Reply-To:Cc: In-Reply-To:References; b=k84n979xXT6XDTcy3hyibbqtDCrg95DhbTR9z7yXBRffYimImz7cUu9RkQNdKXIpq VTclRl6f2ScIcPQ3zUMIE8I3gDjBgX5DtwN0H40Twwq/0wV78t/rz52CAYn1UY4V3r B7NnCw0EhJ8LCU83I5g+wTTXMWvH+9PTwJY7xqew= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by pawpaw.sei.cmu.edu (8.14.4/8.14.4/1456) with ESMTP id tA50HNt6014070 for ; Wed, 4 Nov 2015 19:17: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.0248.002; Wed, 4 Nov 2015 19:17:13 -0500 From: "Roman D. Danyliw" To: "saag@ietf.org" Thread-Topic: DOTS report Thread-Index: AdEXXuEK8EX37spXRlCASF/DlwS+QA== Date: Thu, 5 Nov 2015 00:17:12 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFCD954CA29@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 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:17:24 -0000 DOTS met on Tuesday at 1300 during IETF 94. There were more than 100 atten= dees in the room and Jabber. The WG discussed use cases, requirements and solution oriented drafts. Int= roduced at this meeting were newly published -00 WG drafts covering use cas= es (draft-ietf-dots-use-cases-00) and requirements (draft-ietf-dots-require= ments-00) that consolidated previous individual drafts. An additional indi= vidual draft on use cases (draft-nishizuka-dots-inter-domain-usecases-00) w= as also discussed and the participants suggested a few more. Two solutions drafts (draft-reddy-dots-transport-01 and draft-fu-dots-ipfix= -extension-00) presented early approaches implementing a DOTS messaging for= mat and protocol. A virtual interim meeting is planned for late January or early February. From nobody Wed Nov 4 16:33:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F321B2BF7 for ; Wed, 4 Nov 2015 16:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKjkj60BVnxf for ; Wed, 4 Nov 2015 16:33:00 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4723D1B2BF5 for ; Wed, 4 Nov 2015 16:33:00 -0800 (PST) X-AuditID: 1209190f-f799c6d000001933-92-563aa3ba906e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 60.AC.06451.BB3AA365; Wed, 4 Nov 2015 19:32:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id tA50WwRg022938 for ; Wed, 4 Nov 2015 19:32:58 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA50WrGc030613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 4 Nov 2015 19:32:58 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tA50WrKI019056; Wed, 4 Nov 2015 19:32:53 -0500 (EST) Date: Wed, 4 Nov 2015 19:32:53 -0500 (EST) From: Benjamin Kaduk To: saag@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixG6nort7sVWYwb3ZrBZT+juZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eRsE3PBRq6Klf2v2RsYt3J0MXJySAiYSFz4coEFwhaTuHBv PRuILSSwmEni9jW/LkYuIPsIo8THadsZIZyrTBJ/7+1mhaiql1j69w1TFyMHB4uAlsTPdVEg YTYBFYmZbzaCDRIREJR40DeJBaREGGjB7ztuIGFeAUeJ6VemsoPYogI6Eqv3T2GBiAtKnJz5 BMxmBpq4fPo2lgmMfLOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pS uokRFEickvw7GL8dVDrEKMDBqMTDa1BtFSbEmlhWXJl7iFGSg0lJlPfcTKAQX1J+SmVGYnFG fFFpTmrxIUYJDmYlEd4CkBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeH kgRvzyKgRsGi1PTUirTMnBKENBMHJ8hwHqDh80BqeIsLEnOLM9Mh8qcYFaXEefeCJARAEhml eXC94EjfzaT6ilEc6BVh3o0gVTzAJAHX/QpoMBPQYKZWC5DBJYkIKakGRr/JF/0+OTd9lLuU Eh+24JfpjzNMmw+xbz7YUHDg37mzsqtOLWPtPLFrQuizDA+TDwvvp/TdjJH4fHBCYba75/sJ fHxh1xKm9YsVH3O+8nCD//UXczXeLGU881Ju3QWehR/Xr5neObk25pNeR+/KE7Of3dep6w7W 1Hp993tNlk7Sb40Y3xzW0mVKLMUZiYZazEXFiQBGayZYzwIAAA== Archived-At: Subject: [saag] kitten report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 00:33:01 -0000 *steps out of time machine* kitten met at IETF 95 in Buenos Aires on Friday. Attendance was good, with some 40 participants present. CAMMAC, rfc4402-bis, and aes-cts-hmac-sha2 were published as RFCs since IETF 94, and, pkinit-alg-agility, krb-auth-indicator, and SPAKE preauth are sitting in the RFC Editor's queue. We heard some presentations about post-AES options for Kerberos encryption types and a proposal to make it easier to get code point assignments for GSS-API extensions. Wait, no, no, something's not right; the nametags all say IETF 94, not IETF 95 -- the time machine must have been miscalibrated and taken us back too far! And I've just threatened the integrity of the space-time continuum by revealing information about the future! Ignore everything preceding. Ahem. kitten did not meet at IETF 94, after a slow few months. CAMMAC (which was pulled back from the RFC Editor's queue due to cross-realm use cases being excluded by text regarding copying) made it through another WGLC and should be moving forward soon. rfc4402-bis is ready to be sent to the IESG, and we have a few documents in the WGLC queue, and another few just needing some minor edits before they are ready. -Ben *steps back into borrowedtime machine. Shawn, you really should have that looked at...* From nobody Wed Nov 4 17:30:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61E1B3609 for ; Wed, 4 Nov 2015 17:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I59r-DchhO9G for ; Wed, 4 Nov 2015 17:30:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0076.outbound.protection.outlook.com [207.46.100.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79871B35F6 for ; Wed, 4 Nov 2015 17:30:10 -0800 (PST) Received: from DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) by DM2PR0601MB1118.namprd06.prod.outlook.com (10.160.218.139) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 01:30:09 +0000 Received: from DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) by DM2PR0601MB1118.namprd06.prod.outlook.com ([10.160.218.139]) with mapi id 15.01.0312.014; Thu, 5 Nov 2015 01:30:09 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: JOSE summary for IETF 94 Thread-Index: AQHRF2mCFRUsJtAfGU6UTeqBOpcxbQ== Date: Thu, 5 Nov 2015 01:30:09 +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=odonoghue@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.93.28.54] x-microsoft-exchange-diagnostics: 1; DM2PR0601MB1118; 5:byCDkAIti0VTYcQN55OopklkIl2S7EmYVa6YRmU176YkI6J1FMf9mzY41eRQoInYaOYZT84kAvGZ3C8XREj73YeVIYVR76s/kzGcSOAmkv3oKPtzhptMqaIpiUF/4wF2qKiaaRPIEsxiHYRGrEX7ig==; 24:bvddwLIoTtCeyWsZPjmDVb3M90PP+m8mYUqDG3hCF3t4RVccNMwlzMQTGXgSfPwrklahBW2GR6Pl+TTdMBCoHW2eVrZmPCpr2SuMUMLfy2s=; 20:jPo752Nin+X15vOgIDgIa3/ISfqrLmLE0sIFXNTHAHv1m2N7KQ4BwWriPmjUPWgt//l79PUR27QdLmPWEvFicQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0601MB1118; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:DM2PR0601MB1118; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0601MB1118; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(2351001)(11100500001)(92566002)(82746002)(5001960100002)(5002640100001)(450100001)(19580395003)(99286002)(5004730100002)(122556002)(54356999)(40100003)(86362001)(105586002)(33656002)(15975445007)(83716003)(77096005)(101416001)(5008740100001)(50986999)(229853001)(102836002)(189998001)(5001920100001)(2900100001)(107886002)(87936001)(106116001)(36756003)(97736004)(10400500002)(110136002)(66066001)(81156007)(2501003)(106356001)(5007970100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0601MB1118; H:DM2PR0601MB1118.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <1637ECDF7A860C499A6885B988FE0E2C@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 01:30:09.4039 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0601MB1118 Archived-At: Subject: [saag] JOSE summary for IETF 94 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 01:30:12 -0000 The JOSE wg did not meet during this IETF. Since IETF 93, the JSON Web Key = (JWK) Thumbprint document has been published as RFC 7638.=20 The JWS Unencoded Payload Option draft (https://datatracker.ietf.org/doc/dr= aft-ietf-jose-jws-signing-input-options/) has completed WGLC and will short= ly be sent to the IESG.=20 This is our last remaining work item.= From nobody Wed Nov 4 18:21:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EB81B3691 for ; Wed, 4 Nov 2015 18:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pZCXGMz88mxW for ; Wed, 4 Nov 2015 18:21:10 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 E0FCE1B364D for ; Wed, 4 Nov 2015 18:21:09 -0800 (PST) Received: by lfgh9 with SMTP id h9so51217923lfg.1 for ; Wed, 04 Nov 2015 18:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey_net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=r7eAPyVGM5u6HQatPgJCryvIH6QmYTxdzP7DeKoblog=; b=mmTMXtRHEoc2sEJKpRa83L3/BT9Sr6dp8djvLMaSY/tNnKDZB24PBk6+AnAes3Jqy0 FiJe6aXzkneupGEcEGt7WAU93yXlwtKPBc01/t2gNGpOKntMPERjIyoCABoIxQyEKWge 8ycYzGe3rO8vrtQxT358bBxkKVcVNGjAlxW0TuGRFV+nEByrd+v9aIsBIFuUxuOkLwHz R10e+SnK2GtSMhKWgLwxdxjReC2RYo9ERwf0lQku8PdUekAgvHUu6+bQLUFlCxuuSHLM QB2ui6AAa3EPQAgTX5Ofobg+fKTm0hJTEr3QZlNFC7I5AMo3S9NTdxfJASwyPvH8oKdv kVIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=r7eAPyVGM5u6HQatPgJCryvIH6QmYTxdzP7DeKoblog=; b=Eu/IznaZYWSNh9zM4YZ0wNFHq0NoNsZZkITflsSrsHVZt8w6NieHmQlz1+N76ESYI5 56cSrekIwiSE46L2p9oHDZSLlfwVB5YSFgPYQJz2U9g4TRNzJ4qHiIj7+WlmO0EZEbzJ xTugkg/oEs8PXUMXfpBk153YGN24GndC3i/dvWHokx5JEd6ad5OoIZ14TT8sRm1/T4NC /lMmRdSEvMURYSpOPUEdRuj2JjdG2eVzyTB4/di+PHQowXCqgXYhX6HTw/wJMI8e4SaI JyLTvk8rR/syp5nih0YIIJEJXXfitnXLEmP6BBRAdwRxxdh9juZWqOrS7ALvlD5XAx69 4WbQ== X-Gm-Message-State: ALoCoQlFQK0OnuMPjtlriSB0uruErXwhcIVl0mXdDFF07RZ1CsZLLaqvQykonXNvZtQ6m9ve3j26 MIME-Version: 1.0 X-Received: by 10.25.142.17 with SMTP id q17mr1266306lfd.59.1446690068047; Wed, 04 Nov 2015 18:21:08 -0800 (PST) Received: by 10.112.134.40 with HTTP; Wed, 4 Nov 2015 18:21:07 -0800 (PST) Date: Thu, 5 Nov 2015 11:21:07 +0900 Message-ID: From: Joseph Salowey To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a11401bb29b3c110523c1c7d4 Archived-At: Subject: [saag] TLS Working Group Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:21:12 -0000 --001a11401bb29b3c110523c1c7d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable TLS met on the Wednesday morning session and will have a second session on Thursday afternoon at 17:40. We spent most of the meeting discussing TLS 1.3. Some of the notable items discussed include client authentication, rekey, tls-unique, and cipher suite registry. There was consensus in the meeting to move forward with some changes to finalize client authentication. There was support in the room to add a rekey facility into TLS 1.3. TLS unique needs to be redefined for TLS 1.3 to use keying material exporters, this needs to be handled in a separate document. We also had some discussion of identifying a small set of specific cipher suites as Recommended and leaving the other as use at your own risk. On Thursday afternoon we will continue TLS 1.3 with a discussion of encrypted SNI. We had time for one presentation that discussed making changes based on the TLS 1.2 protocol. There was a general sense of the room that the WG is chartered to =E2=80=9Cmaintain=E2=80=9D TLS 1.2 not =E2=80=9Cextend=E2=80= =9D TLS 1.2 with back ported TLS 1.3 features. There will be a workshop held in co-located with NDSS on 2016-02-21 in San Diego called TRON (TLS Ready or Not) to provide an opportunity for researchers to present their analysis of TLS 1.3. More information can be found here: https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-ca= ll-papers. There are sponsorship opportunities available, if your organization is interested please contact Drew Dvorshak . --001a11401bb29b3c110523c1c7d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TLS=C2=A0met on the Wednesday morning session and will hav= e a second session on Thursday afternoon at 17:40.=C2=A0 We spent most of t= he meeting discussing TLS 1.3. =C2=A0

Some of the notable items dis= cussed include client authentication, rekey, tls-unique, and cipher suite r= egistry. There was consensus in the meeting to move forward with some chang= es to finalize client authentication. =C2=A0 There was support in the room = to add a rekey facility into TLS 1.3. =C2=A0 TLS unique needs to be redefin= ed for TLS 1.3 to use keying material exporters, this needs to be handled i= n a separate document.=C2=A0 We also had some discussion of identifying a s= mall set of specific cipher suites as Recommended and leaving the other as = use at your own risk.=C2=A0 On Thursday afternoon we will continue TLS 1.3 = with a discussion of encrypted SNI. =C2=A0

We had time for one prese= ntation that discussed making changes based on the TLS 1.2 protocol.=C2=A0 = There was a general sense of the room that the WG is chartered to =E2=80=9C= maintain=E2=80=9D TLS 1.2 not =E2=80=9Cextend=E2=80=9D TLS 1.2 with back po= rted TLS 1.3 features.

There will be a workshop held in co-located w= ith NDSS on 2016-02-21 =C2=A0in San Diego called TRON (TLS Ready or Not) to= provide an opportunity for researchers to present their analysis of TLS 1.= 3.=C2=A0 More information can be found here: https://= www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-paper= s. There are sponsorship opportunities available, if your organization = is interested please contact Drew Dvorshak <dvorshak@isoc.org>.
--001a11401bb29b3c110523c1c7d4-- From nobody Wed Nov 4 18:46:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060B21A1A5B for ; Wed, 4 Nov 2015 18:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFN5hI-_Fw1f for ; Wed, 4 Nov 2015 18:46:30 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0751A00F3 for ; Wed, 4 Nov 2015 18:46:30 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1001C28B0041 for ; Wed, 4 Nov 2015 21:46:30 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 5B6E21F8035; Wed, 4 Nov 2015 21:46:29 -0500 (EST) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.1 Content-Type: multipart/signed; boundary="Apple-Mail=_96C8F1F7-8427-4FEC-9EF3-4C09BD6AB18D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 5 Nov 2015 11:46:26 +0900 Message-Id: <3AF36A18-53FC-42DD-985B-8A2D08FDC019@tislabs.com> To: saag@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [saag] SIDR Working Group Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 02:46:32 -0000 --Apple-Mail=_96C8F1F7-8427-4FEC-9EF3-4C09BD6AB18D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 SIDR met Tue evening before the social and will meet Friday morning. We expected to discuss the revamped validation algorithm, but the = primary author instead said he did not see signs that the wg was coming = to consensus and was not willing to continue. He offered to hand the = document over to anyone else. The other authors reported that they also = saw no signs of consensus. At the end of the meeting, there it was = questionable as to whether the work will continue or not. The routing AD (Alvaro) was not happy to see the work end this way. He = asked that we address the issue on Friday morning, taking advantage of = proximity, and attempt to settle whether the work is important and = should continue. Other than that issue, there were presentations about the progress of = the new transport protocol for RPKI (called RRDP - RPKI Repository Delta = Protocol) and about sever years of measurements of one repository = synchronization with the global rpki. Friday we will have two discussions of errors a CA might make. We will = also hear about methods to get public/private key pairs into routers. And a discussion of validation reconsidered. =97Sandy --Apple-Mail=_96C8F1F7-8427-4FEC-9EF3-4C09BD6AB18D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWOsMCAAoJEHplpQeet0IZiFoQAKBDVZBi2joEwKedbtwdo4w4 Anp3nUOEgVw1dzLgXHN2HUuXzxHu+febqY2et894mdGfrDjP+k2WjrGzZLa02TbD x1sMwwlaReUxVhUlVbKsghsG6wIDxvNG2ifU3F6Amldj6snTJhlBLj3w1amuWE8q x+Vcc/9WzripbdhQhEvvE7P6nRxlWaqiW11Y2VRYEojCh0t96SNbAaISD2MR2F0u UvNgNwvkPveur65nIskfu53ccyRPSyaNhk/xNXqVSXzurQLHh6gDITiJQAk+mvkq bVvjK394IACKTmjFXeJNrhhgYEQuc9CLg7X6/7F4nMcwhhIvZTFHqlwzBQgTAkz+ scc/GNXnni2uzcBoi2FYqroefCuOrve3QT8Vfwdz4qgc5kWiJFRGpaZvDe3TMVdq qhsYgExIeiAo6Mttppuxq53n5+hqrzOqLiwhgZNJ4vvzIJzNsHiqGDUGGkTrfPkV lPP5K2PVpc9Dnk3rvMwqDJmW1PEX7JAxM8dkQr36tvCLF8UUsARparaiuJe13/u9 B3ltOWenooquUFsBOjf+R1/dLTvPYdZjm0lzI0tP6QuBjBZQR1pdef6IkU4SSOPf gDxKibh3ZR+e54n5iQaeHhlI4pFfPGqh26C9OxmT0PLPxjdy3UdLWg8/VPY8US00 O/SyYx+J+ll/Z8hNt8NS =fBlT -----END PGP SIGNATURE----- --Apple-Mail=_96C8F1F7-8427-4FEC-9EF3-4C09BD6AB18D-- From nobody Wed Nov 4 19:16:02 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD18E1A049A for ; Wed, 4 Nov 2015 19:16:01 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEU4X18AM_Be for ; Wed, 4 Nov 2015 19:16:00 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3211A039A for ; Wed, 4 Nov 2015 19:16:00 -0800 (PST) Received: by padhx2 with SMTP id hx2so64561621pad.1 for ; Wed, 04 Nov 2015 19:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt_se.20150623.gappssmtp.com; s=20150623; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=kcdM0ZczUd5WN69wnMNaknmYcmWyYPqFA4pVwqUFegY=; b=c0Q9RS1cBdNJb3VqH1vAcsAAfoSC4Y4jjR0TkweW5jWk7WCWqlypINtk7Y4KMy2FlU SghnnddbFd9k6jhXYufUjfAXEQvpbl/cIRs+u4isxLNXXqohhICUyTk9ZYtrQkklF33e ybsvSGP3nehQrEAiFD4HavC9glV2Kt6RqqCqBZmxFjljWNkZnk9SUNoDD3XpU9fr9ELH gU1Yp0RtKYxtCmyCAIrYCGZQfqopRqALQ6L4oOdI8loPPX070i/0V5LHR/EENCbfQEgN wRlz1y+1/V+nTiNi44VAAKNhTlQm13t+ZqccKjrX/DT3omsbaVc0NcoFiv4HUa7IBtNt 55sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:to; bh=kcdM0ZczUd5WN69wnMNaknmYcmWyYPqFA4pVwqUFegY=; b=gZxM4u3MH7PADLhpfpg3jIAb+weMVFzDQej0McA5yQ6fUBwYvipgHggJxHRB4ipExr mV4QOZAIyPegvDXSCVaxm4EBWVhgJCiyH39sXgbtrE/vglBG/iQrXczN8UG1GdSs8eOe b07uyK1/eBkjgQ4Tb8acBWzIUhDUl885vcoZ2H8tXB1gjOP/sVBj8j5fNZg/lGn6FQqs UlgZ0fhs2os1gn6PL1cA8NhdaLFG+ybhnykLZyuPQf0olXqEXu9KxSxWnRVrRglr51vy oyB7LnW7/LQloxS1iYyT30bgFMDKkLs6FVFmHFkX7UtKRsqXx4n55uL+ZaaOZml1eE4v /kmw== X-Gm-Message-State: ALoCoQn57HCCXduX1+hcKqp9aOT2CnlUzjoMdqrxM3jDLhJsJCnw0V2hQAHmXFjhSOx2qae8+tmC X-Received: by 10.68.98.129 with SMTP id ei1mr6328570pbb.7.1446693359922; Wed, 04 Nov 2015 19:15:59 -0800 (PST) Received: from [100.117.5.117] (133.99.142.210.ap.mvno.net. [210.142.99.133]) by smtp.gmail.com with ESMTPSA id hi4sm4734628pbc.7.2015.11.04.19.15.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 19:15:58 -0800 (PST) From: Leif Johansson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <0D6DC483-3672-4A27-9F5F-E38AB0FD7656@mnt.se> Date: Thu, 5 Nov 2015 12:15:56 +0900 To: saag@ietf.org X-Mailer: iPhone Mail (13B143) Archived-At: Subject: [saag] tokbind report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 03:16:02 -0000 The tokbind wg met on Monday. We are making progress and have initiated earl= y allocation if key code points. There are multiple implementations in the w= orks. From nobody Wed Nov 4 19:23:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3C1A8701 for ; Wed, 4 Nov 2015 19:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4iIlyVPmJly for ; Wed, 4 Nov 2015 19:22:59 -0800 (PST) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA9D1A6FE3 for ; Wed, 4 Nov 2015 19:22:59 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 787B640409 for ; Thu, 5 Nov 2015 04:22:57 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 43E95120055 for ; Thu, 5 Nov 2015 04:22:57 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 04:22:56 +0100 From: To: "saag@ietf.org" Thread-Topic: DIME/RADEXT WG report Thread-Index: AdEXeTPFyO6qPfyKRQaVWVVkmtazLA== Date: Thu, 5 Nov 2015 03:22:56 +0000 Message-ID: <27288_1446693777_563ACB91_27288_15196_1_6B7134B31289DC4FAF731D844122B36E01D6147E@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] DIME/RADEXT WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 03:23:03 -0000 On Tuesday (afternoon session I), RADEXT and DIME WG exceptionally share th= e same 2-hour time slot, 1 hour per WG. About 20 people were attending both= WG time slots. For DIME, the main discussion were about trying to find consensus on the re= maining open issue for the Diameter routing message priority. This document= is close to completion and should be sent soon for IESG review. 3GPP has a= dependency on this draft. Another topic is of prime interest for 3GPP: the= document on load control over Diameter. But for this one, no much progress= since the last IETF meeting. More reviews are needed for this document as = well as for the documents on overload control mechanism extensions (Rate co= ntrol and agent overload handling). A deadline for new comments on the Diam= eter Group Signaling document has been set to December, to see if there is = a real need to push forward this document. For the next meeting, it is foreseen that the work on E2E security solution= s will be reactivated as the requirement document is now ready to be publis= hed. For RADEXT, the main discussion was on issues regarding the deployment of R= ADIUS in wi-fi access networks and the specific use of some accounting info= rmation. There is still a need to decide whether an update of the RFC 2866= (detailing the RADIUS accounting part of RFC 26865). On this topic, IEEE f= eedback will be required to ensure that any proposed modification/clarifica= tion will be aligned with their own requirements. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if th= is message was modified, changed or falsified. Thank you. From nobody Wed Nov 4 19:58:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6BF1A89A2 for ; Wed, 4 Nov 2015 19:58:13 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9MzgAc5gZB0 for ; Wed, 4 Nov 2015 19:58:11 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 668231A89FB for ; Wed, 4 Nov 2015 19:58:11 -0800 (PST) Received: by padhx2 with SMTP id hx2so65636184pad.1 for ; Wed, 04 Nov 2015 19:58:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:message-id :references:to; bh=sY2mUKLshbMJvS4B62rXP8tnjEeoCtI1wDmNA3FNsNc=; b=I/geFmyJKOuRqDUxIaph/cYvXYhOUY+L1TCOazbb9LpG8O1mjhjjRmfKXR59qadhuc HCv1JkI/FisyYgRlaj3OWuc9D6HHKPbK8jLpLZEO5jKyFB1ro3PUIxFo4gtL2/J+t66v vthZYVLDnXXDOrjggfCVO1j+lZD32hcbsW+ZyYDxoWkL14VOV0vo6tC3aOnKgq/KMQ3c HdT3PteFmbMz/8IiWLGQ3HHH+BudOi60Ok42s7unshgYTzl5J0rgKQmubo45OqTlETlb 31WcGPoVLBWa2qNn3x364f4UtJtvpQHYwBpTSb0P9v3p3Vl+hNF3bL4P0g9CVTFC1myw xsFQ== X-Received: by 10.66.181.234 with SMTP id dz10mr6688648pac.51.1446695891060; Wed, 04 Nov 2015 19:58:11 -0800 (PST) Received: from t20010c4000003032c51bccef81cec484.v6.meeting.ietf94.jp (t20010c4000003032c51bccef81cec484.v6.meeting.ietf94.jp. [2001:c40:0:3032:c51b:ccef:81ce:c484]) by smtp.gmail.com with ESMTPSA id rm10sm4768030pbc.96.2015.11.04.19.58.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 19:58:09 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_DDD9E286-1977-4F45-BA6A-3A633C70AF15"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Pgp-Agent: GPGMail 2.6b2 From: Adam Montville In-Reply-To: <2F02DD2C-B201-453A-A3A3-953BE805DA16@gmail.com> Date: Thu, 5 Nov 2015 12:57:58 +0900 Message-Id: <69136AC5-1898-4DF4-B759-BF052AE209FA@gmail.com> References: <2F02DD2C-B201-453A-A3A3-953BE805DA16@gmail.com> To: saag@ietf.org X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [saag] SACM Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 03:58:13 -0000 --Apple-Mail=_DDD9E286-1977-4F45-BA6A-3A633C70AF15 Content-Type: multipart/alternative; boundary="Apple-Mail=_44F9D537-6619-494B-BCBD-C0AC3AA5DAA6" --Apple-Mail=_44F9D537-6619-494B-BCBD-C0AC3AA5DAA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Update based on second SACM session. Today, among other things, we discussed SACM Vulnerability Assessment = Scenario = (http://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario/ = ). We are asking for your review on this particular draft, with a = particular focus on its realism. Does the draft appropriately = characterize enterprise vulnerability assessment? Kind regards, Adam > On Nov 4, 2015, at 7:47 AM, Adam Montville = wrote: >=20 > SACM Met on Tuesday (and will meet again on Thursday). >=20 > There were about 50 people in attendance and/or in Jabber. We = reviewed our Requirements, Architecture, and Information Model draft = status. >=20 > Work action between now and Thursday is to make progress on the one = remaining open issue for Requirements so that it may progress to WGLC, = where we expect potential additional feedback. >=20 > We'll be meeting again on Thursday to review solutions draft = submissions, see what work could be done between sessions, and consider = an additional data model construct. >=20 > We expect to plan for two virtual interims between 94 and 95. >=20 --Apple-Mail=_44F9D537-6619-494B-BCBD-C0AC3AA5DAA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Update based on second SACM session.

Today, among other things, we discussed = SACM Vulnerability Assessment Scenario (http://datatracker.ietf.org/doc/draft-coffin-sacm-vuln-scenario= /). 

We= are asking for your review on this particular draft, with a particular = focus on its realism.  Does the draft appropriately characterize = enterprise vulnerability assessment?

Kind regards,

Adam


On Nov 4, 2015, at 7:47 AM, = Adam Montville <adam.w.montville@gmail.com> wrote:

SACM = Met on Tuesday (and will meet again on Thursday).

There were about 50 people in attendance and/or in Jabber. =  We reviewed our Requirements, Architecture, and Information Model = draft status.

Work action between now and = Thursday is to make progress on the one remaining open issue for = Requirements so that it may progress to WGLC, where we expect potential = additional feedback.

We'll be meeting again = on Thursday to review solutions draft submissions, see what work could = be done between sessions, and consider an additional data model = construct.

We expect to plan for two = virtual interims between 94 and 95.


= --Apple-Mail=_44F9D537-6619-494B-BCBD-C0AC3AA5DAA6-- --Apple-Mail=_DDD9E286-1977-4F45-BA6A-3A633C70AF15 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWOtPMAAoJEDEhyx7etgAByXAQAJFuEWf66EkCmuUxzaI5c5ZU RUMcKrwd53Tc4iOOYED+1fK3TNopwGBpF4b138z6zKtcpM6rnSdct22Ln6Ud96GM B21LoiHXH3isi/DgM0qYT1lJEhkHk2Y1vg0XeEmsicVKI7ZELTcFUFezUSFQQSAS gx7exuD0UaiBuVncItKdBZhTxmQedKIx4YGY48AuQgwSVz3JLN3Hnw5cuySTd3N9 YhPRM0f+716Ik8T1f4iP7LGcQXWQcNnJVFDxD7NONGrbbHEo1pEYY0GNSuW5R/l0 CBbIuZ8b79M8oknB6wPKECY6kSjesxXWbnim5Bo39vyk4vVft+TnuSXVpw87It9A EFYoxU3V5WSVHQNy6rULnBu7/gQ++/54fVPFsF96c642gHue8nbvdSUc6mzXcenj RpKg4SPckmLCfCDLtLStolRf1IEuX26LOBRS60ZmY6esTfq4NSoaD0zUiKO2LnYq GkO8sEagDigHNzEPileIvvDrthe4ngZSwjsz1a4Yg4OBRWCg4hBcc7KprBswMw4D j/7NY0dwNZABkAK65nXIabr27jni8ESvfmsnSYxZtNzo/MDp8WuTUJLOaS7YmbTM orS84Zzx0lvFz0YyJRfD5Spm8NmJn9GVe32cIgmMuGxHSQKxsA80Bqu64xolTVSM O8X/j/N/sKYswpBtFf0A =77MH -----END PGP SIGNATURE----- --Apple-Mail=_DDD9E286-1977-4F45-BA6A-3A633C70AF15-- From nobody Wed Nov 4 19:58:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E161A89B0 for ; Wed, 4 Nov 2015 19:58: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_2xHafzCciz for ; Wed, 4 Nov 2015 19:58:32 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 57DEB1A89A2 for ; Wed, 4 Nov 2015 19:58:32 -0800 (PST) Received: by pacdm15 with SMTP id dm15so49431573pac.3 for ; Wed, 04 Nov 2015 19:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=ST6MCpa5LHAyxiyQZhXq/Uj3iF8g0A56aV7l80ajEXE=; b=rPp5lIOKCyET7Jraq9tLvZhlvqCVx1eHI46kzW2jKN8C5D3zpoNb0juqqug4ypLpdD DkoRlesdCLhlGRo0/YNmnWZViAHCbMZKGiQ5p8hW7Aex/YUsUT5jcnf/t40hsYeT5K6c EvXfyeJi1skN5Fqa20DSGwVviK3wvihVcXsi/HN+qeNqdL/+5eO6M7Ac4cJDID0dtNmu fUsfxzcm90xSNxfm1E0foaVuvJMSsyF0EcSlf/9cG0pnQcnPd22sGBfaTavx2t3uvid3 InMVeZWuGWak1ZhNjaL2Oe2HyHFy3IF/ymTMppVBpGcvimgGaM+Ft/5NZnZ2jJpsoVtK HvLQ== X-Received: by 10.66.249.201 with SMTP id yw9mr6656002pac.90.1446695912076; Wed, 04 Nov 2015 19:58:32 -0800 (PST) Received: from t20010c4000003024b96cb2977299f7b5.v6.meeting.ietf94.jp (t20010c4000003024b96cb2977299f7b5.v6.meeting.ietf94.jp. [2001:c40:0:3024:b96c:b297:7299:f7b5]) by smtp.gmail.com with ESMTPSA id kh9sm4865317pad.11.2015.11.04.19.58.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Nov 2015 19:58:31 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <618E749B-A3BB-4491-9326-2BD3D2246397@gmail.com> Date: Thu, 5 Nov 2015 12:58:28 +0900 To: Security Area Advisory Group Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [saag] HTTP-Auth Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 03:58:33 -0000 The HTTP-Auth working group did not meet this time. We have the SCRAM draft in WGLC, hopefully should be sent to Stephen by = the end of the month. That leaves (for now) the three-document set for MutualAuth. There are a = few open issues and there has been precious little review. We hope to be = able to progress this by IETF 95. Yoav & Rifaat= From nobody Wed Nov 4 20:11:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A431E1A9112 for ; Wed, 4 Nov 2015 20:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh7cXQi6aNFL for ; Wed, 4 Nov 2015 20:11:52 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842D71A9024 for ; Wed, 4 Nov 2015 20:11:52 -0800 (PST) Received: from t20010c40000030241db8108f5be81730.v6.meeting.ietf94.jp ([2001:c40:0:3024:1db8:108f:5be8:1730]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZuBtu-000CcS-IL; Thu, 05 Nov 2015 04:11:50 +0000 References: To: saag@ietf.org From: Wendy Seltzer Organization: W3C X-Forwarded-Message-Id: Message-ID: <563AD702.6030809@w3.org> Date: Wed, 4 Nov 2015 23:11:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] W3C Fwd: Charters in development: Web Authentication; Hardware-Based Security (Advance Notice) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:11:54 -0000 FYI and comments welcome: -------- Forwarded Message -------- Subject: Charters in development: Web Authentication; Hardware-Based Security (Advance Notice) Resent-Date: Tue, 27 Oct 2015 08:29:06 +0000 Resent-From: public-new-work@w3.org Date: Tue, 27 Oct 2015 17:28:42 +0900 From: Coralie Mercier Organization: W3C To: public-new-work@w3.org [Apologies; corrected URL below] Hello This is an advance notice that, as the Web Cryptography Working Group is concluding its work, the Team is currently working with Members and the public on two distinct areas of potential new work: Web Authentication and Hardware-Based Security. * Web Authentication: https://w3c.github.io/websec/web-authentication-charter * Hardware-Based Security: https://w3c.github.io/websec/hasec-charter We welcome W3C Advisory Committee representatives' general expressions of interest and support on . Coralie Mercier, Head of W3C Marketing & Communications From nobody Wed Nov 4 20:25:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB41A9138 for ; Wed, 4 Nov 2015 20:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 LJMnJ3fgm_RI for ; Wed, 4 Nov 2015 20:25:47 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 32C301A9132 for ; Wed, 4 Nov 2015 20:25:47 -0800 (PST) Received: by ykek133 with SMTP id k133so111888060yke.2 for ; Wed, 04 Nov 2015 20:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qpa5m/dSoXmzI7EZnX8XZgwfNbd/sZwrVKQ/nloL69g=; b=iWRDwGuAh8OxOVJlj6FfmJNjYyVYUH3Hnr3888i1M/y+iTe87BZomyvxGuPd9e4AgF gO5zu2lGYETD4uDUuwuxUOoEdP7XkNZKHoTS2qoqR+KC5F90xORpds2xMu+TbBrXj0yg PTkkT//2hv8pCs4Uto8fehOe1SCN/O9epjG/Ca12x3B/dNCrfgd4s8okOJiERmJjdN8M +WV61AjNrVGr8HsoO0fpnCdyr5cBAwp8XmdNg5nknllTHDaAf+emSDLWycI/BpFryO/h PKNIKkYtn0uJtZ+uzSd/c849WPgVaCAjLURPSLS6s1Rxf9xtTgyqDD/rLqQV5AhfiFA0 1pvA== MIME-Version: 1.0 X-Received: by 10.129.38.214 with SMTP id m205mr5018157ywm.86.1446697546524; Wed, 04 Nov 2015 20:25:46 -0800 (PST) Received: by 10.37.224.85 with HTTP; Wed, 4 Nov 2015 20:25:46 -0800 (PST) In-Reply-To: <544B0DD62A64C1448B2DA253C011414619276B8B23@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C011414619276B8B23@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 5 Nov 2015 09:55:46 +0530 Message-ID: From: Sarat G To: Rick Andrews Content-Type: multipart/alternative; boundary=001a1141e4b25bb26e0523c3858c Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 04:25:49 -0000 --001a1141e4b25bb26e0523c3858c Content-Type: text/plain; charset=UTF-8 Hi Stephen, Recently I worked on SNMPv3. The SNMP auth protocol still uses HMAC SHA 96 and HMAC MD5 96[RFC 2574]. Thank You. Regards, Sarat G On Thu, Oct 15, 2015 at 11:03 PM, Rick Andrews wrote: > Stephen, OCSP (RFC 6960) mandates SHA-1 for KeyHash, though the risk of > using it here is probably very low. > > --------------- > > Message: 2 > Date: Fri, 9 Oct 2015 14:25:40 +0100 > From: Stephen Farrell > To: "saag@ietf.org" > Subject: [saag] sha1 - have we more work to do? > Message-ID: <5617C054.1070207@cs.tcd.ie> > Content-Type: text/plain; charset=utf-8 > > Hiya, > > While it may be still under submission, and not yet peer reviewed, I was > just looking at [1,2] and wondered if we've still work to do to deprecate > sha1 anywhere that we've not yet done. I know a lot of this was done > already > but just wanted to check that we're good. > > Anyone know places where sha1 is still a should or must or where it's still > in widespread use despite no longer being a should or must? > (No need to mention root stores in browser for that last though, as that's > a > known issue and is I think already being tackled by browser > makers.) > > I guess we can make a list and then figure out what to do if the list is > non-empty. > > Cheers, > S. > > [1] https://sites.google.com/site/itstheshappening/ > [2] https://sites.google.com/site/itstheshappening/shappening_article.pdf > > ------------------------------ > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a1141e4b25bb26e0523c3858c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephen,
Recently I worked on SNMPv3. The SNMP auth= protocol still uses HMAC SHA 96 and HMAC MD5 96[RFC 2574].

Thank You.
Regards,
Sarat G


On Thu, Oct 15, 2015 at 11:03 PM, Rick Andre= ws <Rick_Andrews@symantec.com> wrote:
Stephen, OCSP (RFC 6960) mandates SHA-1 for KeyHash, th= ough the risk of
using it here is probably very low.

---------------

Message: 2
Date: Fri, 9 Oct 2015 14:25:40 +0100
From: Stephen Farrell <step= hen.farrell@cs.tcd.ie>
To: "saag@ietf.org" <saag@ietf.org>
Subject: [saag] sha1 - have we more work to do?
Message-ID: <5617C054.1070= 207@cs.tcd.ie>
Content-Type: text/plain; charset=3Dutf-8

Hiya,

While it may be still under submission, and not yet peer reviewed, I was just looking at [1,2] and wondered if we've still work to do to depreca= te
sha1 anywhere that we've not yet done. I know a lot of this was done al= ready
but just wanted to check that we're good.

Anyone know places where sha1 is still a should or must or where it's s= till
in widespread use despite no longer being a should or must?
(No need to mention root stores in browser for that last though, as that= 9;s a
known issue and is I think already being tackled by browser
makers.)

I guess we can make a list and then figure out what to do if the list is non-empty.

Cheers,
S.

[1] https://sites.google.com/site/itstheshappening/
[2] https://sites.google.com/si= te/itstheshappening/shappening_article.pdf

------------------------------




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


--001a1141e4b25bb26e0523c3858c-- From nobody Wed Nov 4 22:07:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA061B36F2 for ; Wed, 4 Nov 2015 22:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4JlJMG4SNp6 for ; Wed, 4 Nov 2015 22:07:36 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBDE1B3A35 for ; Wed, 4 Nov 2015 22:07:36 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0009C28B003D; Thu, 5 Nov 2015 01:07:35 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 36C6E1F8035; Thu, 5 Nov 2015 01:07:35 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_01FFE837-DE4F-4F22-A72A-56F6596056B0"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Sandra Murphy In-Reply-To: <5617C054.1070207@cs.tcd.ie> Date: Thu, 5 Nov 2015 15:04:09 +0900 Message-Id: References: <5617C054.1070207@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:07:38 -0000 --Apple-Mail=_01FFE837-DE4F-4F22-A72A-56F6596056B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Probably not what you meant, but=85 We had a long discussion in sidr of the potential for collisions from = the use of SHA1 to construct key identifiers. That use is pretty = pervasive, since it comes from rfc5280. =97Sandy On Oct 9, 2015, at 10:25 PM, Stephen Farrell = wrote: >=20 > Hiya, >=20 > While it may be still under submission, and not yet peer reviewed, > I was just looking at [1,2] and wondered if we've still work to do > to deprecate sha1 anywhere that we've not yet done. I know a lot > of this was done already but just wanted to check that we're good. >=20 > Anyone know places where sha1 is still a should or must or where it's > still in widespread use despite no longer being a should or must? > (No need to mention root stores in browser for that last though, as > that's a known issue and is I think already being tackled by browser > makers.) >=20 > I guess we can make a list and then figure out what to do if the > list is non-empty. >=20 > Cheers, > S. >=20 > [1] https://sites.google.com/site/itstheshappening/ > [2] = https://sites.google.com/site/itstheshappening/shappening_article.pdf >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_01FFE837-DE4F-4F22-A72A-56F6596056B0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWOvIlAAoJEHplpQeet0IZIFoP/3g90bXmmYILrSsJXk9TnrAW lPI/CgOsS4/wISXa203LyovzxNo8CR4R5SEkzOu7+Yk703fKyIqzijkHo2UpZOp+ yJJeHWba6wwM98cHiBfg8yUklT2rbR/9IaaL+UI9ISDfYWQw+A+iBqNs9TC+bl+x 19YKWhwhfr7fwbeiC4+ljqQnGKIsXPlg+d6B3kEhQ0Gxvqr/M3nLsnvQ52OpOsyP kr7w5m9TcxNt9gNW9LKvirGz1JOTjv1xLUcDLTsYvYRDaP3pzdjUROWH13p2serH CAPFF90pGMuFdAYwAAeZha898UAJsS4lAXdvLHHyjh4T8SsIK08NiX0MtF/kwqLU FulmWaPJkAMcyqHB6kMvUnAPa7ajP/xJNfHl5ZksC8YS2o1g70yEm4hrR8Rp54OI vRR2to3ivn1JFedhZF/4ffLJC+GHjn3/kgYW6fdalZDrRlus158FqhSwTt2AF35B mfMkLjRiyxsUXbJ1PI8kd5k0dfN5TID85vGZfXMoiOmEFOWHBbgVyqU6sKaRKo+l PUfge4YP0GmM4mkP3l+TvVCaRwniFtlImXvOiDVFxVTgrCrntquOm9bddFPz2dt9 AvQ9+qOGRRp3wmNypEpITd2F5xNGNLTteQIBBpMx3q5ICj0pFxm48y0ho4Ugugk1 1DQ/5MSH0++NKwo8i/m3 =qV+o -----END PGP SIGNATURE----- --Apple-Mail=_01FFE837-DE4F-4F22-A72A-56F6596056B0-- From nobody Wed Nov 4 23:22:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007621B3B42 for ; Wed, 4 Nov 2015 23:22:15 -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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2eE2y6SvYi5 for ; Wed, 4 Nov 2015 23:22:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0B51B3B27 for ; Wed, 4 Nov 2015 23:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=97rozUt0Ojtqy/tmacsEfKMpxKGmCWqWM+ZSQLfKWA8=; b=kYbgwu7ojXqyImpq8MK7KZL6Hmi9doRhuqti2fkX1gad3kB4Q5J77xskWm0d1cIGqLmi3MEczFoDt3Mp/oTpSNS/2vyyIC6IAuORL7ThAJsl2OCLxniWAv9cFhUX73q+eR72sNLi7+qe65Y598YugbEa97AOEzKCYxmj6Usedjc= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) with Microsoft SMTP Server (TLS) id 15.1.312.18; Thu, 5 Nov 2015 07:21:54 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0312.014; Thu, 5 Nov 2015 07:21:54 +0000 From: Christian Huitema To: IETF SAAG Thread-Topic: %G and IP Thread-Index: AdEXmhBwWihg1+hUQEeJrA9ebbMwUw== Date: Thu, 5 Nov 2015 07:21:53 +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=huitema@microsoft.com; x-originating-ip: [133.93.37.74] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0655; 5:CrENV+MCLuzSwZr13sMSROeaqR1/gVZERgHSp6nNeenUaEbpBt67gYveOvvoD+cFsBljXcbWLdSxubt+nygU/7CQ8pZOjoYDso/TaeSkPPDicitzddSOfC/QKLIE0sdlCkEQgiWpLuKpAWXRmBo6aw==; 24:g8QtPIzbRdhsH7n8/PCbMZVpsiqnVnI+/gR3veJoIuujM9uHPoyY8Q10M4q11tEmlwBcBWQeAzaHRxDurQHGl2g33gKWRmJKHa21AexJTNE=; 20:hGoj5o13qLM5BHqrbgh1oksCr641DWQrCmZfYmJWTKkog/k5T+v4+cu4TdAebwn6HxeKDvcdi08aP/XwoSNzNw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42140001); SRVR:DM2PR0301MB0655; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426024)(61427024); SRVR:DM2PR0301MB0655; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0655; x-forefront-prvs: 0751474A44 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5001960100002)(122556002)(81156007)(5003600100002)(99286002)(5002640100001)(66066001)(105586002)(5004730100002)(97736004)(19580405001)(450100001)(5007970100001)(15975445007)(102836002)(19580395003)(189998001)(77096005)(87936001)(106356001)(229853001)(107886002)(110136002)(2900100001)(19300405004)(11100500001)(40100003)(74316001)(33656002)(54356999)(8990500004)(50986999)(10290500002)(5005710100001)(86362001)(10090500001)(10400500002)(86612001)(76576001)(92566002)(16236675004)(5008740100001)(19625215002)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0655; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0655A3514A0F891578154BABA8290DM2PR0301MB0655_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2015 07:21:53.7752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0655 Archived-At: Subject: [saag] %G and IP X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:22:15 -0000 --_000_DM2PR0301MB0655A3514A0F891578154BABA8290DM2PR0301MB0655_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable During the sec area meeting, I mentioned the mailing list set after the MAR= NEW workshop, with the goal of providing a meeting place for IETF and 3GPP = experts. The idea is to influence the 5G architecture to make it more "TCP-= IP friendly." The list is: 5gangip@ietf.org The subscription page is: https://www.ietf.org/mailman/listinfo/5gangip -- Christian Huitema --_000_DM2PR0301MB0655A3514A0F891578154BABA8290DM2PR0301MB0655_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

During the sec area meeting, I mentioned the mailing list se= t after the MARNEW workshop, with the goal of providing a meeting place for= IETF and 3GPP experts. The idea is to influence the 5G architecture to make it more “TCP-IP friendly.”

 

The list is: 5gangip@ietf.org

The subscription page is: https://www.ietf.org/mailman/listi= nfo/5gangip

 

-- Christian Huitema

 

--_000_DM2PR0301MB0655A3514A0F891578154BABA8290DM2PR0301MB0655_-- From nobody Wed Nov 4 23:46:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1681B2BEA for ; Wed, 4 Nov 2015 23:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV70sI7P1jL5 for ; Wed, 4 Nov 2015 23:46:28 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BBA1B3B85 for ; Wed, 4 Nov 2015 23:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2492; q=dns/txt; s=iport; t=1446709588; x=1447919188; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=LEFpscg85PjJf1Hken48p/2APyON5/5uALgzRxFDw0E=; b=cOiGU+lINwmpTzIIDt6uoEsfGD4K8yBBhNBtkYrtG8S28PkDAj7u5WJ6 RKpCmNT9pOUmQU+qRw9u+Cubv/ua/umkcaaiiib2Xinho6QMoHaqA7njj njnq8bNpe3yg3sSefzUF6xkyP+2bIHHH5DWGAVhZd/z4h4m0LwjSCnj4w w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQBSCDtW/5pdJa1egztTdb1qAQ2BXiOHJTgUAQEBAQEBAX8LhDyBCwGBACYBBBuIJg2hBaBiAQEBBwEBAQEBGgSGVIkoEQGEfAWNVIh0AYUch3+BYYQ/licBHwEBQoQEhFA6gQcBAQE X-IronPort-AV: E=Sophos;i="5.20,246,1444694400"; d="scan'208";a="205448364" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Nov 2015 07:46:27 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tA57kRwB023466 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 5 Nov 2015 07:46:27 GMT Received: from xch-aln-012.cisco.com (173.36.7.22) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 5 Nov 2015 01:46:27 -0600 Received: from xch-aln-012.cisco.com ([173.36.7.22]) by XCH-ALN-012.cisco.com ([173.36.7.22]) with mapi id 15.00.1104.000; Thu, 5 Nov 2015 01:46:27 -0600 From: "Shaun Cooley (shcooley)" To: "saag@ietf.org" Thread-Topic: Confidential Group Communications Thread-Index: AdEXngHUQiB7QU92STqEhf7EvlDiZA== Date: Thu, 5 Nov 2015 07:46:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.16.77] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Confidential Group Communications X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 07:46:30 -0000 This is a follow up to my 60 second speed pitch from today's open session..= . Questions:=20 - How can we represent and manage group membership in a way that is verifi= able, tamper-proof, and practical in both centralized and decentralized top= ologies? - How do we share encryption keys for resources shared within the group? - How do we federate group membership and keys between a single group that= spans multiple central authorities? - How do we have groups that consist of a mix of both centralized and dece= ntralized users? Our first draft, draft-abiggs-saag-primitives-for-conf-group-comms-01, defi= nes two primitives that can be used to answer the above questions. Specifi= cally, a Group Membership Block Chain (GMBC) and a Group Key (GK). Additio= nally, the draft defines both a centralized and decentralized model, introd= uces the concept of a "curator" for the centralized model, and provides nom= inal sequences for each model. A Group Membership Block Chain (GMBC) is. - a ledger of group membership updates over time - a publicly verifiable record of membership and policy - tamper-proof based on public key authentication - supports zero-conflict centralized topologies - supports conflict-resolution in decentralized topologies A Group Key (GK) is. - a standard JOSE JSON representation that wraps a content key with the pu= blic keys of each other GMBC group members. - an object that can be shared openly without compromising confidentiality Our second draft, draft-abiggs-saag-key-management-service-03, provides det= ails of a centralized confidential group communication model that is derive= d from the primitives listed above and lists communication sequences for HT= TP file sharing and XMPP. We will publish a third draft in the near future to further detail the use = of the primitives in a decentralized model. If anyone else is working in this area, we'd like to chat and hopefully col= laborate! Please reach out to me via email or find me in Yokohama tonight = or tomorrow. I'll be at the Intercontinental lobby bar after Bits-n-Bites = tonight. The drafts: - https://tools.ietf.org/html/draft-abiggs-saag-primitives-for-conf-group-= comms-01 - https://tools.ietf.org/html/draft-abiggs-saag-key-management-service-03 I also mentioned a related draft by Martin Thomson and Adam Roach, which ca= n be found at: - https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 -Shaun From nobody Thu Nov 5 00:48:17 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C386F1A8A96 for ; Thu, 5 Nov 2015 00:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkYrHU0nQq_7 for ; Thu, 5 Nov 2015 00:48:14 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 936D51A8A94 for ; Thu, 5 Nov 2015 00:48:14 -0800 (PST) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA58mCMT004128 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 5 Nov 2015 03:48:13 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA58mCMT004128 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446713293; bh=YAec44ThdMTyUO/KfLo2GwYHXjo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=wzSUAHF8aOrmQ7a9aiLpCRCaytW05asf3n1/LIfL0QjiR/7TdYxd82tp0rznQDeUv EgV3/xXpU/cfOVZC06c2aEkg2wOzXq103VdWO3CKZOOqobS9Ch1CH2hyT7Isvp7yJ5 2uLhVo8bvyzB2KU6taS7loNHNCB7lzD6ZWvam1+Q= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA58mCMT004128 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Thu, 5 Nov 2015 03:47:45 -0500 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA58m3a5008838 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 5 Nov 2015 03:48:03 -0500 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub09.corp.emc.com (10.254.92.104) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 5 Nov 2015 03:48:02 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0266.001; Thu, 5 Nov 2015 03:48:02 -0500 From: "Black, David" To: "saag@ietf.org" Thread-Topic: TCPINC Working Group Report Thread-Index: AdEXpqYGJcnQ6OmmSu2oi45OUdVr6A== Date: Thu, 5 Nov 2015 08:48:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.60.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [saag] TCPINC Working Group Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:48:15 -0000 TCPINC (in the TSV Area) met Wednesday before the plenary. Since Prague, the WG has two new chairs (Mirja Kuehlewind, David Black) and= has now adopted three drafts, a TCP encryption negotiation option (TCP-ENO= ) draft and two drafts for security protocols that will be negotiated via t= hat option, tcpcrypt and a TLS profile for TCP (aka TCP-use-TLS). There wa= s also WG meeting discussion of proposed socket and OS API modifications fo= r TCP-ENO. Discussion of a possible STUN-like service to check functionality (e.g., wr= t NATs) and related use of DHCP suggested that a separate draft would be ap= propriate rather than tacking this material onto an API draft. Discussion = also favored simplicity of the TLS profile for TCP - all support for certi= ficates and versions of TLS other than TLS 1.3 belongs in a separately iden= tified protocol profile that could also be negotiated via TCP-ENO. The WG hopes to have sufficiently complete, detailed and stable protocol sp= ecifications that will be suitable for external expert review (e.g., Transp= ort, Security) by sometime in February of next year. Thanks, --David (for David & Mirja) From nobody Thu Nov 5 17:56:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAB91B2AF7 for ; Thu, 5 Nov 2015 17:56:02 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9yyoUJ6Ib2c for ; Thu, 5 Nov 2015 17:56:00 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 7BAB11B2AF2 for ; Thu, 5 Nov 2015 17:56:00 -0800 (PST) Received: by padhx2 with SMTP id hx2so97076349pad.1 for ; Thu, 05 Nov 2015 17:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S6fUCjU0OhXkeM1cZ36CpDk9Byr0ZF3sLq2euTVNDnM=; b=QbI30fpsirIPabioh2CFy90OP0IFMylj47oN0nmDz789kta8nj8jv2zUFAvM+5xwdI 6h2/pVxqkMcLYfcnV4TyBv1kjUWpg19WkYjZZh3l1vRzaOy8veHfcPOQKmc92T0jMgbg OcfxAyv367M1CuE1mgtzrWQit1k+OUGq/O5Ec= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=S6fUCjU0OhXkeM1cZ36CpDk9Byr0ZF3sLq2euTVNDnM=; b=kftBYLAnG54nyk08GVN1BiBphwuiJ2mWMTD/uOq8TTkDLR1FIEHHS9IzmlyIAAqVRw SP3HJHe6JL6aZmySVVjvbeCAYlntUykX1DVrjZozwhN3rY7F4Q1AmOFFSC8iT6TjB+gg sAbk8HbGepQ6gudEsIEXOOZqP2GwsbuLLAaBj9I8b5LVlr0zw6SC5DqWcuniA03yinhI Sw5mhxwEyAww2iYl+qLVckb/CRWnWQEskMpahQyjqK7HjHbA/SC4HPghQxDcQkTCGuzk cQkLBE/jCcYYUXid+tLA90n9iDD+r+EwAkDe+fL+YWy5q2UaQpwR02qWF/Aa/OlDAIsB MAEg== X-Gm-Message-State: ALoCoQnybc9fHyvj8kzKBzrMxijjOHzwnik2FVjaD8kzMOl9qs7RbM6mlPrItcaFjScpZ9Sdt4vV X-Received: by 10.66.192.164 with SMTP id hh4mr13456457pac.150.1446774960161; Thu, 05 Nov 2015 17:56:00 -0800 (PST) Received: from t20010c4000003024bde6cc771d5ef1b1.v6.meeting.ietf94.jp (t20010c4000003024bde6cc771d5ef1b1.v6.meeting.ietf94.jp. [2001:c40:0:3024:bde6:cc77:1d5e:f1b1]) by smtp.gmail.com with ESMTPSA id pq1sm10195336pbb.91.2015.11.05.17.55.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2015 17:55:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Sean Turner In-Reply-To: Date: Fri, 6 Nov 2015 10:55:56 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <508F8973-D61A-49DF-A52B-CC8E8920C9E6@sn3rd.com> References: <544B0DD62A64C1448B2DA253C011414619276B8B23@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: Sarat G X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "saag@ietf.org" , Rick Andrews Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 01:56:02 -0000 This is pretty new, but might a step in the right direction = http://datatracker.ietf.org/doc/rfc7630/. spt > On Nov 05, 2015, at 13:25, Sarat G = wrote: >=20 > Hi Stephen, > Recently I worked on SNMPv3. The SNMP auth protocol still uses HMAC = SHA 96 and HMAC MD5 96[RFC 2574]. >=20 > Thank You. > Regards, > Sarat G >=20 >=20 >=20 > On Thu, Oct 15, 2015 at 11:03 PM, Rick Andrews = wrote: > Stephen, OCSP (RFC 6960) mandates SHA-1 for KeyHash, though the risk = of > using it here is probably very low. >=20 > --------------- >=20 > Message: 2 > Date: Fri, 9 Oct 2015 14:25:40 +0100 > From: Stephen Farrell > To: "saag@ietf.org" > Subject: [saag] sha1 - have we more work to do? > Message-ID: <5617C054.1070207@cs.tcd.ie> > Content-Type: text/plain; charset=3Dutf-8 >=20 > Hiya, >=20 > While it may be still under submission, and not yet peer reviewed, I = was > just looking at [1,2] and wondered if we've still work to do to = deprecate > sha1 anywhere that we've not yet done. I know a lot of this was done = already > but just wanted to check that we're good. >=20 > Anyone know places where sha1 is still a should or must or where it's = still > in widespread use despite no longer being a should or must? > (No need to mention root stores in browser for that last though, as = that's a > known issue and is I think already being tackled by browser > makers.) >=20 > I guess we can make a list and then figure out what to do if the list = is > non-empty. >=20 > Cheers, > S. >=20 > [1] https://sites.google.com/site/itstheshappening/ > [2] = https://sites.google.com/site/itstheshappening/shappening_article.pdf >=20 > ------------------------------ >=20 >=20 >=20 >=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 Thu Nov 5 18:17:45 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8B1B2D1F for ; Thu, 5 Nov 2015 18:17:44 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 042eC5s0W1hs for ; Thu, 5 Nov 2015 18:17:43 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E751B2D1E for ; Thu, 5 Nov 2015 18:17:42 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 3325E6D748; Thu, 5 Nov 2015 21:17:42 -0500 (EST) To: saag@ietf.org References: <56398CBD.9050109@cs.tcd.ie> From: ianG Message-ID: <563C0DC5.1080104@iang.org> Date: Fri, 6 Nov 2015 02:17:41 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56398CBD.9050109@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 02:17:44 -0000 On 4/11/2015 04:42 am, Stephen Farrell wrote: > At the secdir lunch this week in Yokohama we spoke about needing > a bit of organisation around adding new curves and about deprecating > some old algs (e.g. sha1). > > There's a scattered set of stuff that'll need doing some of which > is in progress (e.g. drafts allocating OIDs for new curves so they > can appear in certificates), others of which may not yet be. > > One possibility would be to try do this as a WG with a charter > that tightly defines which new things can be added but allows > for deprecating anything that should be deprecated. Add it to the charter of each WG? OK. My strawman thought of the last week was that every Security section in every future RFC should have a rollover / deprecation plan added to it. Bring the question of 2025 back to now - how does the designer of the protocol today think this should happen in 2025? As I say, just a strawman, light your matches and throw... > The putative WG here would not I think tackle items where we have > a current WG active, e.g. TLS can handle defining codepoints for TLS. > > As a separate but related thing, Alexey said he'd create a cfrg > wiki page where folks could add the names of drafts that are > defining things related to new curves. That might feed into the > positive parts of chartering. I'd not suggest passing "control" of new stuff across to CFRG or drafts, etc. I would still leave control of the cipher suite with the designer (editor?) of the protocol. This is the person best able to make the compromise call at the moment, and impose it on the next 20 years of users. > FWIW, if this is something people support and find useful, Kathleen > and I are happy to help it happen. Next step would likely be to > start a mailing list for this and see if there's enough energy to > get stuff going. (If there is, I doubt a BoF would be needed.) > > Thoughts? Mammoth task :) Won't get started unless it's started... iang From nobody Thu Nov 5 18:19:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464131B2D2D for ; Thu, 5 Nov 2015 18:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 413z9lp_r5GR for ; Thu, 5 Nov 2015 18:19:28 -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 B6F011B2D25 for ; Thu, 5 Nov 2015 18:19:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4DC4EBDF9; Fri, 6 Nov 2015 02:19:27 +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 foQLqcZVnS3U; Fri, 6 Nov 2015 02:19:25 +0000 (GMT) Received: from [133.93.24.87] (unknown [133.93.24.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6C57DBDCB; Fri, 6 Nov 2015 02:19:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446776365; bh=goqRprCCVbRWagRZOz5iaYU7ra8bkeHyt737XGTrc2c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=awYgtfCMVbTUmCIpDYxdyaQJnehu6rutkzgqDYfWkNrIixqCSyaWtjvt/6oo4z7sx cyI0n0V06WoQjnvWirC9H0+NgtU4G5iF+MD64adO/nTEpjpTs19RwzG8wgFlK4tKVd ssJDVEIpi0562Xyd7sJV5wtBzmJQN6h7a/qvM0m8= To: ianG , saag@ietf.org References: <56398CBD.9050109@cs.tcd.ie> <563C0DC5.1080104@iang.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <563C0E2A.7030400@cs.tcd.ie> Date: Fri, 6 Nov 2015 02:19:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563C0DC5.1080104@iang.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 02:19:30 -0000 On 06/11/15 02:17, ianG wrote: > On 4/11/2015 04:42 am, Stephen Farrell wrote: >> At the secdir lunch this week in Yokohama we spoke about needing >> a bit of organisation around adding new curves and about deprecating >> some old algs (e.g. sha1). >> >> There's a scattered set of stuff that'll need doing some of which >> is in progress (e.g. drafts allocating OIDs for new curves so they >> can appear in certificates), others of which may not yet be. >> >> One possibility would be to try do this as a WG with a charter >> that tightly defines which new things can be added but allows >> for deprecating anything that should be deprecated. > > > Add it to the charter of each WG? OK. No that's not what I meant. We have protocols for which there is no current WG. S. > > My strawman thought of the last week was that every Security section in > every future RFC should have a rollover / deprecation plan added to it. > Bring the question of 2025 back to now - how does the designer of the > protocol today think this should happen in 2025? > > As I say, just a strawman, light your matches and throw... > > >> The putative WG here would not I think tackle items where we have >> a current WG active, e.g. TLS can handle defining codepoints for TLS. >> >> As a separate but related thing, Alexey said he'd create a cfrg >> wiki page where folks could add the names of drafts that are >> defining things related to new curves. That might feed into the >> positive parts of chartering. > > > I'd not suggest passing "control" of new stuff across to CFRG or drafts, > etc. I would still leave control of the cipher suite with the designer > (editor?) of the protocol. This is the person best able to make the > compromise call at the moment, and impose it on the next 20 years of users. > > >> FWIW, if this is something people support and find useful, Kathleen >> and I are happy to help it happen. Next step would likely be to >> start a mailing list for this and see if there's enough energy to >> get stuff going. (If there is, I doubt a BoF would be needed.) >> >> Thoughts? > > > Mammoth task :) Won't get started unless it's started... > > > > iang > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Fri Nov 6 02:16:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1641B38AA for ; Fri, 6 Nov 2015 02:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 PursE4VhwiGu for ; Fri, 6 Nov 2015 02:16:00 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 CEC0E1B38AC for ; Fri, 6 Nov 2015 02:15:59 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tA6AFnu8000739 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 6 Nov 2015 11:15:50 +0100 From: Simon Josefsson To: Stephen Farrell References: <56398CBD.9050109@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151106:saag@ietf.org::c3D/qY64AlVa+php:NQYq X-Hashcash: 1:22:151106:stephen.farrell@cs.tcd.ie::Px+bE5WVBvLZ7yNY:Fv0a Date: Fri, 06 Nov 2015 11:15:48 +0100 In-Reply-To: <56398CBD.9050109@cs.tcd.ie> (Stephen Farrell's message of "Wed, 4 Nov 2015 04:42:37 +0000") Message-ID: <87y4ebzb57.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 10:16:01 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > Hiya, > > At the secdir lunch this week in Yokohama we spoke about needing > a bit of organisation around adding new curves and about deprecating > some old algs (e.g. sha1). > > There's a scattered set of stuff that'll need doing some of which > is in progress (e.g. drafts allocating OIDs for new curves so they > can appear in certificates), others of which may not yet be. > > One possibility would be to try do this as a WG with a charter > that tightly defines which new things can be added but allows > for deprecating anything that should be deprecated. I believe fleshing out more details would help to establish wether this is a good idea or not. To be concrete, I perceive this to be about adding support for Curve25519 key-agreement, Ed25519 digital signatures, and ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also chose Curve448 we ought to include X448/Ed448, although before the CFRG decision I saw close to zero demand from implementers so it will be pushing things down people's throats and will lead to agility complexity concerns but I believe we are okay with that (it would be boring if we had no protocol weaknesses to fix). The protocols that would be relevant are SSH (no active WG), PKIX (no active WG), and DNSSEC (no DNS protocol-related active WG). I believe OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON there is a proposal but no public WG discussion. The Kerberos community have not been active in pursuing modern crypto. Regarding deprecating SHA1, what is there really to be done? What RFCs needs updating? Does it make sense to have a WG to take on SSH, PKIX and DNSSEC protocol work? Personally I feel the difficulty for each of the proposals have been protocol-specific and not crypto-specific so that any cross-polination between the work that we may get to see is not likely to motivate the cost of setting up a new WG. However, I do not know what was discussed at the secdir lunch so I may be missing context. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWPH3UAAoJEIYLf7sy+BGdmQ0H+QHfy/5/UV1pERJXA3SmVhnX 1c69PRgOjjhsA0IeCFDGcfRCEBcZzmzJHAhEgMuQe2sVkoWvg8nHU8/XsOJFp0F+ /if333GJqCT1ZfJlfRIBQF4gFUk6dbl9t+xvXu1adHV6XIavIW0RGEACpQNudtdK m5JgmLYYRFu1/mZNa8U8g82vrISYoWl5WpkWiynn/6OlaQCaSeXsOJmxVsDjPavp mCMAE03UxtuRTbrkPg1e6II1vJeuoMbNs0+Z+DzH7EuItvsB732g7iPY1ipcZcZq x/umjfi9VsmRGuqc4VPzsKYFGhKlbnJ7Olmu/49Pazj5jFRVgSQ2HDKfQzFtvCY= =hFF2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 6 02:41:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC021B390F for ; Fri, 6 Nov 2015 02:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5uaF2_VyiNT for ; Fri, 6 Nov 2015 02:41:08 -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 C6C581B390B for ; Fri, 6 Nov 2015 02:41:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35243BDCB; Fri, 6 Nov 2015 10:41:05 +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 jrJWlmxBx5g0; Fri, 6 Nov 2015 10:41:03 +0000 (GMT) Received: from [10.71.5.10] (unknown [101.110.53.38]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B50ABDCA; Fri, 6 Nov 2015 10:41:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446806463; bh=D4eM6GstQV2iw+gDY1+XuNVGkSGI1QPnlcyEJ2Z8NBE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=iVrU61m+8ynv/Z27NI0O0WFxjg9M3qK9Bcxs/Iy9LT97t5V7+OJPFyCl7G5p4NkGN e9/amk9/Gg0vU+yfQi2BakI49Iro6fSTQgys7pfNcehKVIK8Xph69A7uPnPLvAifHb alpcUtuCfrmNAAcQxzbxaKV+piyDILBq3wlrYK4M= To: Simon Josefsson References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <563C83BC.2030903@cs.tcd.ie> Date: Fri, 6 Nov 2015 10:41:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87y4ebzb57.fsf@latte.josefsson.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 10:41:10 -0000 Hi Simon, On 06/11/15 10:15, Simon Josefsson wrote: > Stephen Farrell writes: > >> Hiya, >> >> At the secdir lunch this week in Yokohama we spoke about needing >> a bit of organisation around adding new curves and about deprecating >> some old algs (e.g. sha1). >> >> There's a scattered set of stuff that'll need doing some of which >> is in progress (e.g. drafts allocating OIDs for new curves so they >> can appear in certificates), others of which may not yet be. >> >> One possibility would be to try do this as a WG with a charter >> that tightly defines which new things can be added but allows >> for deprecating anything that should be deprecated. > > I believe fleshing out more details would help to establish wether this > is a good idea or not. Thanks for that. (Been a busy week and I didn't get around to it.) > > To be concrete, I perceive this to be about adding support for > Curve25519 key-agreement, Ed25519 digital signatures, and > ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also > chose Curve448 we ought to include X448/Ed448, although before the CFRG > decision I saw close to zero demand from implementers so it will be > pushing things down people's throats and will lead to agility complexity > concerns but I believe we are okay with that (it would be boring if we > had no protocol weaknesses to fix). > > The protocols that would be relevant are SSH (no active WG), PKIX (no > active WG), and DNSSEC (no DNS protocol-related active WG). I believe > OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON > there is a proposal but no public WG discussion. The Kerberos community > have not been active in pursuing modern crypto. Kerberos has the kitten wg as well so is fine. > Regarding deprecating SHA1, what is there really to be done? What RFCs > needs updating? That'd need to be fleshed out during chartering or in the wg. I personally think it'd be fine to deprecate any old crypto where there's rough consensus (in the wg and IETF-wide) for that. And adding the above algs to any protocol would also seem ok. > > Does it make sense to have a WG to take on SSH, PKIX and DNSSEC protocol > work? The main reason (for me at least) is that processing a whole bunch of AD sponsored documents may take longer. Handling more than one of those at a time is tricky and each last call takes a month in the best case, longer if there's any controversy. And if there were a wg I'd hope someone would have had time to check around and see if there're any other places that need updates. > Personally I feel the difficulty for each of the proposals have been > protocol-specific and not crypto-specific so that any cross-polination > between the work that we may get to see is not likely to motivate the > cost of setting up a new WG. However, I do not know what was discussed > at the secdir lunch so I may be missing context. Setting up a wg like this isn't costly once there's a few folks willing to chair/edit and enough to credibly review. Cheers, S. > > /Simon > From nobody Fri Nov 6 07:23:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC771AC3CB for ; Fri, 6 Nov 2015 07:23:42 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku5bOkO74iO6 for ; Fri, 6 Nov 2015 07:23:39 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 6AFE51AC3B7 for ; Fri, 6 Nov 2015 07:23:39 -0800 (PST) Received: by wmnn186 with SMTP id n186so44807003wmn.1 for ; Fri, 06 Nov 2015 07:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P+9dOSfS3EBV8jLW6H62/cOoIy5ywOyYJfduTsLYd4g=; b=kfvBITgEM+YcrJIdoWb3Hu7AJl3ZmwW0hE6dizOywHOVJDhCnBzu4L26E3THFlltj1 7tFHcowAsH7kntotoUWaZ5YRzL3uftIm4zpAaDJsQqbk/0qOi5W0q1QXPvLuVQihSdcS nMDe39lxIKeUlKiixe/TCY5IKDc5jSa/GTghB01nXKx4bMLHb8lHjVo8UOJEXPgcT211 GkbXo6UiIqABECMwi4Uq7HlfCMiPJjGBTcqNydFYyG+ZLYk7xro7Cyrmi3tXpoNjG02u 5FTsOWv7srulTF48JVWQTx6OJE53tAi1x3IyoWZSeWs79X5ODLYx2BUEBfsYQbSnT5/F Sykw== MIME-Version: 1.0 X-Received: by 10.28.137.194 with SMTP id l185mr10446127wmd.21.1446823417890; Fri, 06 Nov 2015 07:23:37 -0800 (PST) Received: by 10.28.101.212 with HTTP; Fri, 6 Nov 2015 07:23:37 -0800 (PST) In-Reply-To: <87y4ebzb57.fsf@latte.josefsson.org> References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> Date: Fri, 6 Nov 2015 10:23:37 -0500 Message-ID: From: Watson Ladd To: Simon Josefsson Content-Type: multipart/alternative; boundary=001a114421e8e04f320523e0d3b9 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2015 15:23:42 -0000 --001a114421e8e04f320523e0d3b9 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 5:15 AM, Simon Josefsson wrote: > Stephen Farrell writes: > >> Hiya, >> >> At the secdir lunch this week in Yokohama we spoke about needing >> a bit of organisation around adding new curves and about deprecating >> some old algs (e.g. sha1). >> >> There's a scattered set of stuff that'll need doing some of which >> is in progress (e.g. drafts allocating OIDs for new curves so they >> can appear in certificates), others of which may not yet be. >> >> One possibility would be to try do this as a WG with a charter >> that tightly defines which new things can be added but allows >> for deprecating anything that should be deprecated. > > I believe fleshing out more details would help to establish wether this > is a good idea or not. > > To be concrete, I perceive this to be about adding support for > Curve25519 key-agreement, Ed25519 digital signatures, and > ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also > chose Curve448 we ought to include X448/Ed448, although before the CFRG > decision I saw close to zero demand from implementers so it will be > pushing things down people's throats and will lead to agility complexity > concerns but I believe we are okay with that (it would be boring if we > had no protocol weaknesses to fix). > > The protocols that would be relevant are SSH (no active WG), PKIX (no > active WG), and DNSSEC (no DNS protocol-related active WG). I believe > OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON > there is a proposal but no public WG discussion. The Kerberos community > have not been active in pursuing modern crypto. OpenSSH has already deployed Curve25519, and written a description of how to do it. PKIX I believe is being dealt with in TLS by some people, but I don't know. Fundamentally if vendors want to change the work will be done, and if they don't the work is useless. > > Regarding deprecating SHA1, what is there really to be done? What RFCs > needs updating? > > Does it make sense to have a WG to take on SSH, PKIX and DNSSEC protocol > work? > > Personally I feel the difficulty for each of the proposals have been > protocol-specific and not crypto-specific so that any cross-polination > between the work that we may get to see is not likely to motivate the > cost of setting up a new WG. However, I do not know what was discussed > at the secdir lunch so I may be missing context. > > /Simon > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- "Man is born free, but everywhere he is in chains". --Rousseau. --001a114421e8e04f320523e0d3b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 6, 2015 at 5:15 AM, Simon Josefsson <simon@josefsson.org&g= t; wrote:
> Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:
>
>> Hiya,
>>
>> At the secdir lunch this week in Yokohama we spoke about needing >> a bit of organisation around adding new curves and about deprecati= ng
>> some old algs (e.g. sha1).
>>
>> There's a scattered set of stuff that'll need doing some o= f which
>> is in progress (e.g. drafts allocating OIDs for new curves so they=
>> can appear in certificates), others of which may not yet be.
>>
>> One possibility would be to try do this as a WG with a charter
>> that tightly defines which new things can be added but allows
>> for deprecating anything that should be deprecated.
>
> I believe fleshing out more details would help to establish wether thi= s
> is a good idea or not.
>
> To be concrete, I perceive this to be about adding support for
> Curve25519 key-agreement, Ed25519 digital signatures, and
> ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also<= br> > chose Curve448 we ought to include X448/Ed448, although before the CFR= G
> decision I saw close to zero demand from implementers so it will be > pushing things down people's throats and will lead to agility comp= lexity
> concerns but I believe we are okay with that (it would be boring if we=
> had no protocol weaknesses to fix).
>
> The protocols that would be relevant are SSH (no active WG), PKIX (no<= br> > active WG), and DNSSEC (no DNS protocol-related active WG). I believe<= br> > OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON<= br> > there is a proposal but no public WG discussion. The Kerberos communit= y
> have not been active in pursuing modern crypto.

OpenSSH has already deployed Curve25519, and written a descr= iption of how to do it. PKIX I believe is being dealt with in TLS by some p= eople, but I don't know. Fundamentally if vendors want to change the wo= rk will be done, and if they don't the work is useless.

>
> Regarding deprecating SHA1, what is there really to be done? What RFCs=
> needs updating?
>
> Does it make sense to have a WG to take on SSH, PKIX and DNSSEC protoc= ol
> work?
>
> Personally I feel the difficulty for each of the proposals have been > protocol-specific and not crypto-specific so that any cross-polination=
> between the work that we may get to see is not likely to motivate the<= br> > cost of setting up a new WG. However, I do not know what was discussed=
> at the secdir lunch so I may be missing context.
>
> /Simon
>
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a114421e8e04f320523e0d3b9-- From nobody Fri Nov 6 22:09:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9751B2B49 for ; Fri, 6 Nov 2015 22:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xIu9Y0Du31e for ; Fri, 6 Nov 2015 22:09:33 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10371B2B4A for ; Fri, 6 Nov 2015 22:09:32 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-f6-563d959b32ae Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 89.81.19232.B959D365; Sat, 7 Nov 2015 01:09:31 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tA769ULJ013872; Sat, 7 Nov 2015 01:09:31 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tA769RgO011262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Nov 2015 01:09:29 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tA769QQR010954; Sat, 7 Nov 2015 01:09:26 -0500 (EST) Date: Sat, 7 Nov 2015 01:09:26 -0500 (EST) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <563C83BC.2030903@cs.tcd.ie> Message-ID: References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrjt7qm2YQf8TVYsp/Z1MFve2XGK3 mL73GrsDs8fa7qtsHkuW/GTymHnmInsAcxSXTUpqTmZZapG+XQJXxu3f3xkLzvFU3J91gqmB sYGri5GTQ0LAROLnmUuMELaYxIV769m6GLk4hAQWM0ncvrWLEcLZwCjxZ/VZJgjnIJPEj097 WEBahATqJZqeLwFrZxHQkth8sJEJxGYTUJGY+WYjG4gtIqAvsXfzOfYuRg4OZgEviWVrwUqE BWwlHrydCGZzCmhKvJ72lB3E5hVwlPg/9yszxPgsiQenF4HFRQV0JFbvn8ICUSMocXLmEzCb GWjt8unbWCYwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZG UPBySvLvYPx2UOkQowAHoxIP74YfNmFCrIllxZW5hxglOZiURHlLYmzDhPiS8lMqMxKLM+KL SnNSiw8xSnAwK4nwfskFyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAo SfCyTwFqFCxKTU+tSMvMKUFIM3FwggznARoePhlkeHFBYm5xZjpE/hSjopQ4rwhIswBIIqM0 D64XnFx2M6m+YhQHekWYVxmkigeYmOC6XwENZgIa7BBlAzK4JBEhJdXAuPjq1nulDpznojKt V66t64mTKMg56PnzY8KlyR5iBqEcXmnSvamKBwMeVGgWbfzmq3q55dgvbSfH4hfvtm5OnG6q WzLh0qlfOlI6LUdud317zLx7QUHGvLYjpvlfymO9Jt6K2VDEzKAfKTH5jr746hUVn5Q0bb+8 WLKYtbfX8VqOwu+nAiEmSizFGYmGWsxFxYkAepBOXAkDAAA= Archived-At: Cc: Simon Josefsson , "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 06:09:34 -0000 On Fri, 6 Nov 2015, Stephen Farrell wrote: > > On 06/11/15 10:15, Simon Josefsson wrote: > > > > To be concrete, I perceive this to be about adding support for > > Curve25519 key-agreement, Ed25519 digital signatures, and > > ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also > > chose Curve448 we ought to include X448/Ed448, although before the CFRG > > decision I saw close to zero demand from implementers so it will be > > pushing things down people's throats and will lead to agility complexity > > concerns but I believe we are okay with that (it would be boring if we > > had no protocol weaknesses to fix). > > > > The protocols that would be relevant are SSH (no active WG), PKIX (no > > active WG), and DNSSEC (no DNS protocol-related active WG). I believe > > OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON > > there is a proposal but no public WG discussion. The Kerberos community > > have not been active in pursuing modern crypto. I'm not sure if you're referring to the people who still haven't switched off of single-DES (yes, really! Quite a few of them!), or a lack of interest in post-AES/sha1. > Kerberos has the kitten wg as well so is fine. On the face of it, maybe. There is a draft proposing AES/SHA2 enctypes, which got some attention, but the WG is a bit low on energy in general. Some extra folks helping pull in, e.g., ChaChaa20-Poly1305 would be quite welcome. The elephant in the room is that if Microsoft doesn't implement a new enctype for AD, it is unlikely to see widespread adoption. -Ben From nobody Sat Nov 7 05:31:07 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA88F1A0031 for ; Sat, 7 Nov 2015 05:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.954 X-Spam-Level: X-Spam-Status: No, score=0.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 v9dN7GWTujfK for ; Sat, 7 Nov 2015 05:31:04 -0800 (PST) Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB291A002F for ; Sat, 7 Nov 2015 05:31:03 -0800 (PST) Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id 9E91141E96 for ; Sat, 7 Nov 2015 14:30:45 +0100 (CET) Received: from iMassi.local (unknown [210.160.37.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id 5E4E718926B8 for ; Sat, 7 Nov 2015 08:30:37 -0500 (EST) To: "saag@ietf.org" From: Massimiliano Pala Organization: OpenCA Labs Message-ID: <563DFCFB.8090405@openca.org> Date: Sat, 7 Nov 2015 22:30:35 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 13:31:05 -0000 Hi all, I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail. The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities). Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at: http://cryptoapi.openca.org/ Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest". Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address. Happy Security Everybody! Cheers, Max P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS). From nobody Sat Nov 7 06:00:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2161A1A91 for ; Sat, 7 Nov 2015 05:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbBGw94_r1g3 for ; Sat, 7 Nov 2015 05:59:55 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 91C2F1A1A90 for ; Sat, 7 Nov 2015 05:59:55 -0800 (PST) Received: by igvi2 with SMTP id i2so50252945igv.0 for ; Sat, 07 Nov 2015 05:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Sz+vZmEnz3Tx9Zlzh1RjDlBoo5+lDhVEOcRQUIAO9A=; b=lVj5kFCtTW7L3GssgUnvo0RPDfIzWtwY9lZZSaoprX8+75NTmqZTyB20SJIQUuDe/f hYtPSKdKtDMNrKwY+xJW75GHPet+lNDf9OmG6tqlrwwBuwcomJQ3iuCvtq9554mD20RW 7h8pkGyEQV1TV8r49y9KI+VyQgm8Jw+Yzxon2eyirHFc7hhgMETLyditigLYTk9nbAsh yqFxbTcrSrCiWc6ZYsvQPDSKdTqgFd726FK0xlnDanbROzU6BBekMAVH4mDEhrmatgp4 ra23Lyxqx4+706TtceYFrrcj69ZsSa4YGRYKcWJQtWaRA5lAcx1VfOVDUs13Rw7rtQiL sVzw== MIME-Version: 1.0 X-Received: by 10.50.28.50 with SMTP id y18mr1567082igg.12.1446904794924; Sat, 07 Nov 2015 05:59:54 -0800 (PST) Received: by 10.50.89.201 with HTTP; Sat, 7 Nov 2015 05:59:54 -0800 (PST) In-Reply-To: <563DFCFB.8090405@openca.org> References: <563DFCFB.8090405@openca.org> Date: Sat, 7 Nov 2015 14:59:54 +0100 Message-ID: From: Jaroslav Imrich To: Massimiliano Pala Content-Type: multipart/alternative; boundary=089e0158a9bc534c190523f3c647 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 13:59:59 -0000 --089e0158a9bc534c190523f3c647 Content-Type: text/plain; charset=UTF-8 Hi Max, I believe PKCS#11 [0] already provides those benefits, it is widely adopted by both commercial and open-source projects and it works not only for hardware but also for pure software crypto implementations - for example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What would be the benefits of the new API over PKCS#11? Regards, Jaroslav [0] https://www.oasis-open.org/committees/pkcs11/ [1] https://www.opendnssec.org/softhsm/ [2] http://thewalter.net/git/cgit.cgi/p11-capi/ On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala wrote: > Hi all, > > I am not sure this is the right place to write this e-mail, but I hope is. > At the meeting I spoke with several people about an idea I had some time > ago but never landed at IETF. Since I got positive feedback and suggestion > to post the idea to this list to see if others might be interested, here's > the summary e-mail. > > The idea is very simple: provide specifications for interfaces to > cryptographic libraries. The basic idea is to provide an API that different > vendors can implement on top of their libraries to provide a standard > interface for applications. If successful, an application could make use of > OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that > interface without having to re-write the crypto-related code. This allows > for portability (wider adoption of crypto-enabled applications), > code/modules re-usability, and the possibility for applications to switch > between vendors (e.g., switching to a better crypto library or dismissing a > library that has shown vulnerabilities). > > Although I received positive feedback about the idea (I know, it has be > attempted in the past.. ), I was never able to get the green light to > proceed with a proposal for IETF (unfortunately the answer was always "we > don't do APIs" ... which, actually, it is not true), so I decided to move > forward anyway, since it is a real pain that needs to be solved. If the > IETF will like to pick up the work in the future, great. If not, we'll > solve the problem anyway :D > > If you are interested in participating in the effort (e.g., writing specs, > participating in the discussion, provide feedback, or writing code) please > contact me and we'll take it from there. I wrote a couple of pages today > (very quick and dirty work for now.. so.. don't judge!), but I hope we'll > be able to gather momentum and work together on this. The website is > reachable at: > > http://cryptoapi.openca.org/ > > Last but not least - I am starting also another project that targets the > use of SYMMETRIC crypto by providing support for encryption at rest. This > library will provide support for storing encrypted data, signed (hmac) > data, symmetric keys, and symmetric keys bundles (stack of keys) in such a > way that it is simple to use (e.g., dealing with symmetric crypto is hard > for the average developer since not much support, outside TLS, is > provided). By defining a simple high-level API for symmetric crypto we want > to fill the gap and, hopefully, increase the use of crypto also in those > environment where asymmetric is not an option (e.g., latency constraints). > The idea is to actually write a standard for symmetric crypto ... "at rest". > > Also for this project, please contact me directly (I still do not have > pages for this project for various reasons - most importantly I still have > to see if I get to open source what I did for my employer of if we have to > start from scratch) at this e-mail address. > > Happy Security Everybody! > > Cheers, > Max > > P.S.: Other items on the back burner that I would welcome contributions to > are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI > Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public > Key (Discovery) System (PKS). > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --089e0158a9bc534c190523f3c647 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Max,

I believe PKCS#1= 1 [0] already provides those benefits, it is widely adopted by both commerc= ial and open-source projects and it works not only for hardware but also fo= r pure software crypto implementations - for example SoftHSM [1] works nice= ly on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What = would be the benefits of the new API over PKCS#11?

=
Regards, Jaroslav

On Sat, N= ov 7, 2015 at 2:30 PM, Massimiliano Pala <director@openca.org> wrote:
Hi all,

I am not sure this is the right place to write this e-mail, but I hope is. = At the meeting I spoke with several people about an idea I had some time ag= o but never landed at IETF. Since I got positive feedback and suggestion to= post the idea to this list to see if others might be interested, here'= s the summary e-mail.

The idea is very simple: provide specifications for interfaces to cryptogra= phic libraries. The basic idea is to provide an API that different vendors = can implement on top of their libraries to provide a standard interface for= applications. If successful, an application could make use of OpenSSL, MS-= CAPI, Cryptlib, or any other crypto library that provides that interface wi= thout having to re-write the crypto-related code. This allows for portabili= ty (wider adoption of crypto-enabled applications), code/modules re-usabili= ty, and the possibility for applications to switch between vendors (e.g., s= witching to a better crypto library or dismissing a library that has shown = vulnerabilities).

Although I received positive feedback about the idea (I know, it has be att= empted in the past.. ), I was never able to get the green light to proceed = with a proposal for IETF (unfortunately the answer was always "we don&= #39;t do APIs" ... which, actually, it is not true), so I decided to m= ove forward anyway, since it is a real pain that needs to be solved. If the= IETF will like to pick up the work in the future, great. If not, we'll= solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing specs, = participating in the discussion, provide feedback, or writing code) please = contact me and we'll take it from there. I wrote a couple of pages toda= y (very quick and dirty work for now.. so.. don't judge!), but I hope w= e'll be able to gather momentum and work together on this. The website = is reachable at:

=C2=A0 =C2=A0 http://cryptoapi.openca.org/

Last but not least - I am starting also another project that targets the us= e of SYMMETRIC crypto by providing support for encryption at rest. This lib= rary will provide support for storing encrypted data, signed (hmac) data, s= ymmetric keys, and symmetric keys bundles (stack of keys) in such a way tha= t it is simple to use (e.g., dealing with symmetric crypto is hard for the = average developer since not much support, outside TLS, is provided). By def= ining a simple high-level API for symmetric crypto we want to fill the gap = and, hopefully, increase the use of crypto also in those environment where = asymmetric is not an option (e.g., latency constraints). The idea is to act= ually write a standard for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have page= s for this project for various reasons - most importantly I still have to s= ee if I get to open source what I did for my employer of if we have to star= t from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions to = are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Res= ource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (= Discovery) System (PKS).


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--089e0158a9bc534c190523f3c647-- From nobody Sat Nov 7 06:10:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B47D1A88C0 for ; Sat, 7 Nov 2015 06:10:11 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30ONFKgKuw3i for ; Sat, 7 Nov 2015 06:10:08 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 6ACEC1A8908 for ; Sat, 7 Nov 2015 06:10:08 -0800 (PST) Received: by wmww144 with SMTP id w144so47781361wmw.1 for ; Sat, 07 Nov 2015 06:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0sf3JYAvbix8TeOtjV7Yg2xofZ13vjdCAt+9NXm+y18=; b=XlMXzWjseG0YAA+X1fyCT9IQLGYTf/pCG7PMtqcpvmIJ+huLk5YSLMStuAY8/+PVxV pILnkYHMnYCrSDqkFdjhDCWFN/i0Q8RHB45o/S7ImVkFr8ypyE3/NU+a9Tp17l8aG0Z8 0IxopB7nr+tIw0hSJ7zxEZlh/ABvjiaBt/FFOz3Z9Cdo1wtJwA1gFtovjyZw+SRHP69k r+d9X5JWVTpJkzlhlT9SzN5RWdsb1BMAWX+bIOJZJHo6pJXna3l2hbfaPv4+mAQH40HK l88RNpYF0gFs/9THYftY3Hky8qwOyo49jfFSOun9mDcT7TCRdl6Ocg91vWZPa/0khzDx 8f0w== MIME-Version: 1.0 X-Received: by 10.28.137.194 with SMTP id l185mr15336673wmd.21.1446905406765; Sat, 07 Nov 2015 06:10:06 -0800 (PST) Received: by 10.28.101.212 with HTTP; Sat, 7 Nov 2015 06:10:06 -0800 (PST) In-Reply-To: References: <563DFCFB.8090405@openca.org> Date: Sat, 7 Nov 2015 09:10:06 -0500 Message-ID: From: Watson Ladd To: Jaroslav Imrich Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2015 14:10:11 -0000 On Sat, Nov 7, 2015 at 8:59 AM, Jaroslav Imrich wrote: > Hi Max, > > I believe PKCS#11 [0] already provides those benefits, it is widely adopted > by both commercial and open-source projects and it works not only for > hardware but also for pure software crypto implementations - for example > SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on > top of MS CAPI. What would be the benefits of the new API over PKCS#11? It would be sane. For whatever reason encrypt_aes_gcm(unsigned char *nonce, unsigned char *key, unsigned char *out, unsigned char *in, size_t inlen) is a function that isn't provided by most libraries that implement AES-GCM. The result is that users have to deal with an incredibly painful amount of boilerplate, concealing flaws. > > Regards, Jaroslav > > [0] https://www.oasis-open.org/committees/pkcs11/ > [1] https://www.opendnssec.org/softhsm/ > [2] http://thewalter.net/git/cgit.cgi/p11-capi/ > > > On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala > wrote: >> >> Hi all, >> >> I am not sure this is the right place to write this e-mail, but I hope is. >> At the meeting I spoke with several people about an idea I had some time ago >> but never landed at IETF. Since I got positive feedback and suggestion to >> post the idea to this list to see if others might be interested, here's the >> summary e-mail. >> >> The idea is very simple: provide specifications for interfaces to >> cryptographic libraries. The basic idea is to provide an API that different >> vendors can implement on top of their libraries to provide a standard >> interface for applications. If successful, an application could make use of >> OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that >> interface without having to re-write the crypto-related code. This allows >> for portability (wider adoption of crypto-enabled applications), >> code/modules re-usability, and the possibility for applications to switch >> between vendors (e.g., switching to a better crypto library or dismissing a >> library that has shown vulnerabilities). >> >> Although I received positive feedback about the idea (I know, it has be >> attempted in the past.. ), I was never able to get the green light to >> proceed with a proposal for IETF (unfortunately the answer was always "we >> don't do APIs" ... which, actually, it is not true), so I decided to move >> forward anyway, since it is a real pain that needs to be solved. If the IETF >> will like to pick up the work in the future, great. If not, we'll solve the >> problem anyway :D >> >> If you are interested in participating in the effort (e.g., writing specs, >> participating in the discussion, provide feedback, or writing code) please >> contact me and we'll take it from there. I wrote a couple of pages today >> (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be >> able to gather momentum and work together on this. The website is reachable >> at: >> >> http://cryptoapi.openca.org/ >> >> Last but not least - I am starting also another project that targets the >> use of SYMMETRIC crypto by providing support for encryption at rest. This >> library will provide support for storing encrypted data, signed (hmac) data, >> symmetric keys, and symmetric keys bundles (stack of keys) in such a way >> that it is simple to use (e.g., dealing with symmetric crypto is hard for >> the average developer since not much support, outside TLS, is provided). By >> defining a simple high-level API for symmetric crypto we want to fill the >> gap and, hopefully, increase the use of crypto also in those environment >> where asymmetric is not an option (e.g., latency constraints). The idea is >> to actually write a standard for symmetric crypto ... "at rest". >> >> Also for this project, please contact me directly (I still do not have >> pages for this project for various reasons - most importantly I still have >> to see if I get to open source what I did for my employer of if we have to >> start from scratch) at this e-mail address. >> >> Happy Security Everybody! >> >> Cheers, >> Max >> >> P.S.: Other items on the back burner that I would welcome contributions to >> are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI >> Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key >> (Discovery) System (PKS). >> >> >> _______________________________________________ >> 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 > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Nov 7 21:38:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5A41B399B for ; Sat, 7 Nov 2015 21:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 Pn2TUPq28RLQ for ; Sat, 7 Nov 2015 21:38:40 -0800 (PST) Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFDA1B399A for ; Sat, 7 Nov 2015 21:38:39 -0800 (PST) Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id EC7A741D85; Sun, 8 Nov 2015 06:38:21 +0100 (CET) Received: from iMassi.local (ip-64-134-234-172.public.wayport.net [64.134.234.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id AAC571899745; Sun, 8 Nov 2015 00:38:15 -0500 (EST) To: Jaroslav Imrich References: <563DFCFB.8090405@openca.org> From: Massimiliano Pala Organization: OpenCA Labs Message-ID: <563EDFC6.2050102@openca.org> Date: Sun, 8 Nov 2015 00:38:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090203060908020806020307" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 05:38:43 -0000 This is a multi-part message in MIME format. --------------090203060908020806020307 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jaroslav, thanks for the feedback. I do understand your position - however, I do disagree with the premises. PKCS#11 is a successful standard when it comes to hardware interfaces. However, since its design was targeted to standardizing interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to applications. Therefore much work is required to fill those gaps (only using PKCS#11 calls does get you only that far). This said, I think that learning from the limitations of the solutions we have today is an important step towards specifying the scope of the proposed work. Maybe we will end up having a similar API or we might provide an higher level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try to address a real pain by using the only standard API we have today. A commendable effort, but not what I am proposing. Another important aspect that is usually under-estimated when it comes to crypto APIs is usability. I personally think that PKCS#11 is not a great example from this point of view and, AFAIK, people that have developed against it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, developers need to use other interfaces to deal with all extra details when it comes to, for example, dealing with certificates processing (e.g., chain validation, etc.). This is my personal opinion, of course, and I do not want to start a discussion about if this work is needed or not here (especially because I have already been told that IETF is not interested in this work). I think there is much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who practically have felt the pain when developing applications) as possible. If you feel that this is still a pain point today, please join the effort. Thanks again for the feedback, Cheers, Max On 11/7/15 8:59 AM, Jaroslav Imrich wrote: > Hi Max, > > I believe PKCS#11 [0] already provides those benefits, it is widely > adopted by both commercial and open-source projects and it works not > only for hardware but also for pure software crypto implementations - > for example SoftHSM [1] works nicely on top of OpenSSL and Botan, > p11-capi [2] works on top of MS CAPI. What would be the benefits of > the new API over PKCS#11? > > Regards, Jaroslav > > [0] https://www.oasis-open.org/committees/pkcs11/ > [1] https://www.opendnssec.org/softhsm/ > [2] http://thewalter.net/git/cgit.cgi/p11-capi/ > > > On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala > wrote: > > Hi all, > > I am not sure this is the right place to write this e-mail, but I > hope is. At the meeting I spoke with several people about an idea > I had some time ago but never landed at IETF. Since I got positive > feedback and suggestion to post the idea to this list to see if > others might be interested, here's the summary e-mail. > > The idea is very simple: provide specifications for interfaces to > cryptographic libraries. The basic idea is to provide an API that > different vendors can implement on top of their libraries to > provide a standard interface for applications. If successful, an > application could make use of OpenSSL, MS-CAPI, Cryptlib, or any > other crypto library that provides that interface without having > to re-write the crypto-related code. This allows for portability > (wider adoption of crypto-enabled applications), code/modules > re-usability, and the possibility for applications to switch > between vendors (e.g., switching to a better crypto library or > dismissing a library that has shown vulnerabilities). > > Although I received positive feedback about the idea (I know, it > has be attempted in the past.. ), I was never able to get the > green light to proceed with a proposal for IETF (unfortunately the > answer was always "we don't do APIs" ... which, actually, it is > not true), so I decided to move forward anyway, since it is a real > pain that needs to be solved. If the IETF will like to pick up the > work in the future, great. If not, we'll solve the problem anyway :D > > If you are interested in participating in the effort (e.g., > writing specs, participating in the discussion, provide feedback, > or writing code) please contact me and we'll take it from there. I > wrote a couple of pages today (very quick and dirty work for now.. > so.. don't judge!), but I hope we'll be able to gather momentum > and work together on this. The website is reachable at: > > http://cryptoapi.openca.org/ > > Last but not least - I am starting also another project that > targets the use of SYMMETRIC crypto by providing support for > encryption at rest. This library will provide support for storing > encrypted data, signed (hmac) data, symmetric keys, and symmetric > keys bundles (stack of keys) in such a way that it is simple to > use (e.g., dealing with symmetric crypto is hard for the average > developer since not much support, outside TLS, is provided). By > defining a simple high-level API for symmetric crypto we want to > fill the gap and, hopefully, increase the use of crypto also in > those environment where asymmetric is not an option (e.g., latency > constraints). The idea is to actually write a standard for > symmetric crypto ... "at rest". > > Also for this project, please contact me directly (I still do not > have pages for this project for various reasons - most importantly > I still have to see if I get to open source what I did for my > employer of if we have to start from scratch) at this e-mail address. > > Happy Security Everybody! > > Cheers, > Max > > P.S.: Other items on the back burner that I would welcome > contributions to are OCSP over DNS (ODIN), Lightweight Revocation > Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified > CMC over HTTP, and the Public Key (Discovery) System (PKS). > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --------------090203060908020806020307 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jaroslav,

thanks for the feedback. I do understand your position - however, I do disagree with the premises. PKCS#11 is a successful standard when it comes to hardware interfaces. However, since its design was targeted to standardizing interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to applications. Therefore much work is required to fill those gaps (only using PKCS#11 calls does get you only that far).

This said, I think that learning from the limitations of the solutions we have today is an important step towards specifying the scope of the proposed work. Maybe we will end up having a similar API or we might provide an higher level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try to address a real pain by using the only standard API we have today. A commendable effort, but not what I am proposing.

Another important aspect that is usually under-estimated when it comes to crypto APIs is usability. I personally think that PKCS#11 is not a great example from this point of view and, AFAIK, people that have developed against it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, developers need to use other interfaces to deal with all extra details when it comes to, for example, dealing with certificates processing (e.g., chain validation, etc.).

This is my personal opinion, of course, and I do not want to start a discussion about if this work is needed or not here (especially because I have already been told that IETF is not interested in this work). I think there is much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who practically have felt the pain when developing applications) as possible. If you feel that this is still a pain point today, please join the effort.

Thanks again for the feedback,

Cheers,
Max


On 11/7/15 8:59 AM, Jaroslav Imrich wrote:
Hi Max,

I believe PKCS#11 [0] already provides those benefits, it is widely adopted by both commercial and open-source projects and it works not only for hardware but also for pure software crypto implementations - for example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What would be the benefits of the new API over PKCS#11?

Regards, Jaroslav


On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <director@openca.org> wrote:
Hi all,

I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at:

    http://cryptoapi.openca.org/

Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS).


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

--------------090203060908020806020307-- From nobody Sat Nov 7 21:44:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916B31A00F3 for ; Sat, 7 Nov 2015 21:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjFrhAsDKxwj for ; Sat, 7 Nov 2015 21:44:48 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D4B4B1A00F1 for ; Sat, 7 Nov 2015 21:44:47 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 1BF46F2417A; Sun, 8 Nov 2015 00:44:37 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id kWJMZFhoTv0c; Sun, 8 Nov 2015 00:43:10 -0500 (EST) Received: from [192.168.19.159] (unknown [165.225.100.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5EADDF2416C; Sun, 8 Nov 2015 00:44:12 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-78-502808864 From: Russ Housley In-Reply-To: <563EDFC6.2050102@openca.org> Date: Sun, 8 Nov 2015 00:44:03 -0500 Message-Id: <090207A0-65F1-4605-B19B-AF0DDFBF61E1@vigilsec.com> References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> To: Massimiliano Pala X-Mailer: Apple Mail (2.1085) Archived-At: Cc: IETF SAAG Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 05:44:51 -0000 --Apple-Mail-78-502808864 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Max: Wouldn't the ideal API be the same for software libraries and hardware = devices? Having the application seamlessly work regardless of the = manner that the key is stored would be a big win for application = developers. To this end, some people use PKCS#11 as an interface to = software. Russ On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote: > Hi Jaroslav, >=20 > thanks for the feedback. I do understand your position - however, I do = disagree with the premises. PKCS#11 is a successful standard when it = comes to hardware interfaces. However, since its design was targeted to = standardizing interfaces for hardware devices, it does not always = provide the easiest / best approach when it comes to applications. = Therefore much work is required to fill those gaps (only using PKCS#11 = calls does get you only that far). >=20 > This said, I think that learning from the limitations of the solutions = we have today is an important step towards specifying the scope of the = proposed work. Maybe we will end up having a similar API or we might = provide an higher level one or, again, a simplified version of it. In my = opinion, all the solutions you are listing here try to address a real = pain by using the only standard API we have today. A commendable effort, = but not what I am proposing. >=20 > Another important aspect that is usually under-estimated when it comes = to crypto APIs is usability. I personally think that PKCS#11 is not a = great example from this point of view and, AFAIK, people that have = developed against it have often resorted to develop their own = abstraction layer on top of it. Moreover, most of the times, developers = need to use other interfaces to deal with all extra details when it = comes to, for example, dealing with certificates processing (e.g., chain = validation, etc.). >=20 > This is my personal opinion, of course, and I do not want to start a = discussion about if this work is needed or not here (especially because = I have already been told that IETF is not interested in this work). I = think there is much to be done and I am happy to discuss all these = aspects and collaborate with as many experts (who practically have felt = the pain when developing applications) as possible. If you feel that = this is still a pain point today, please join the effort. >=20 > Thanks again for the feedback, >=20 > Cheers, > Max >=20 >=20 > On 11/7/15 8:59 AM, Jaroslav Imrich wrote: >> Hi Max, >>=20 >> I believe PKCS#11 [0] already provides those benefits, it is widely = adopted by both commercial and open-source projects and it works not = only for hardware but also for pure software crypto implementations - = for example SoftHSM [1] works nicely on top of OpenSSL and Botan, = p11-capi [2] works on top of MS CAPI. What would be the benefits of the = new API over PKCS#11? >>=20 >> Regards, Jaroslav >>=20 >> [0] https://www.oasis-open.org/committees/pkcs11/ >> [1] https://www.opendnssec.org/softhsm/ >> [2] http://thewalter.net/git/cgit.cgi/p11-capi/ >>=20 >>=20 >> On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala = wrote: >> Hi all, >>=20 >> I am not sure this is the right place to write this e-mail, but I = hope is. At the meeting I spoke with several people about an idea I had = some time ago but never landed at IETF. Since I got positive feedback = and suggestion to post the idea to this list to see if others might be = interested, here's the summary e-mail. >>=20 >> The idea is very simple: provide specifications for interfaces to = cryptographic libraries. The basic idea is to provide an API that = different vendors can implement on top of their libraries to provide a = standard interface for applications. If successful, an application could = make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that = provides that interface without having to re-write the crypto-related = code. This allows for portability (wider adoption of crypto-enabled = applications), code/modules re-usability, and the possibility for = applications to switch between vendors (e.g., switching to a better = crypto library or dismissing a library that has shown vulnerabilities). >>=20 >> Although I received positive feedback about the idea (I know, it has = be attempted in the past.. ), I was never able to get the green light to = proceed with a proposal for IETF (unfortunately the answer was always = "we don't do APIs" ... which, actually, it is not true), so I decided to = move forward anyway, since it is a real pain that needs to be solved. If = the IETF will like to pick up the work in the future, great. If not, = we'll solve the problem anyway :D >>=20 >> If you are interested in participating in the effort (e.g., writing = specs, participating in the discussion, provide feedback, or writing = code) please contact me and we'll take it from there. I wrote a couple = of pages today (very quick and dirty work for now.. so.. don't judge!), = but I hope we'll be able to gather momentum and work together on this. = The website is reachable at: >>=20 >> http://cryptoapi.openca.org/ >>=20 >> Last but not least - I am starting also another project that targets = the use of SYMMETRIC crypto by providing support for encryption at rest. = This library will provide support for storing encrypted data, signed = (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) = in such a way that it is simple to use (e.g., dealing with symmetric = crypto is hard for the average developer since not much support, outside = TLS, is provided). By defining a simple high-level API for symmetric = crypto we want to fill the gap and, hopefully, increase the use of = crypto also in those environment where asymmetric is not an option = (e.g., latency constraints). The idea is to actually write a standard = for symmetric crypto ... "at rest". >>=20 >> Also for this project, please contact me directly (I still do not = have pages for this project for various reasons - most importantly I = still have to see if I get to open source what I did for my employer of = if we have to start from scratch) at this e-mail address. >>=20 >> Happy Security Everybody! >>=20 >> Cheers, >> Max >>=20 >> P.S.: Other items on the back burner that I would welcome = contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens = (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over = HTTP, and the Public Key (Discovery) System (PKS). >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-78-502808864 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Max:

Wouldn't the ideal API be the same for software libraries and hardware devices?  Having the application seamlessly work regardless of the manner that the key is stored would be a big win for application developers.  To this end, some people use PKCS#11 as an interface to software.

Russ


On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote:

Hi Jaroslav,

thanks for the feedback. I do understand your position - however, I do disagree with the premises. PKCS#11 is a successful standard when it comes to hardware interfaces. However, since its design was targeted to standardizing interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to applications. Therefore much work is required to fill those gaps (only using PKCS#11 calls does get you only that far).

This said, I think that learning from the limitations of the solutions we have today is an important step towards specifying the scope of the proposed work. Maybe we will end up having a similar API or we might provide an higher level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try to address a real pain by using the only standard API we have today. A commendable effort, but not what I am proposing.

Another important aspect that is usually under-estimated when it comes to crypto APIs is usability. I personally think that PKCS#11 is not a great example from this point of view and, AFAIK, people that have developed against it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, developers need to use other interfaces to deal with all extra details when it comes to, for example, dealing with certificates processing (e.g., chain validation, etc.).

This is my personal opinion, of course, and I do not want to start a discussion about if this work is needed or not here (especially because I have already been told that IETF is not interested in this work). I think there is much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who practically have felt the pain when developing applications) as possible. If you feel that this is still a pain point today, please join the effort.

Thanks again for the feedback,

Cheers,
Max


On 11/7/15 8:59 AM, Jaroslav Imrich wrote:
Hi Max,

I believe PKCS#11 [0] already provides those benefits, it is widely adopted by both commercial and open-source projects and it works not only for hardware but also for pure software crypto implementations - for example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What would be the benefits of the new API over PKCS#11?

Regards, Jaroslav


On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <director@openca.org> wrote:
Hi all,

I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at:

    http://cryptoapi.openca.org/

Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS).


_______________________________________________
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

--Apple-Mail-78-502808864-- From nobody Sun Nov 8 04:53:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E045D1B2BA9 for ; Sun, 8 Nov 2015 04:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 KqRRb8V5Ipks for ; Sun, 8 Nov 2015 04:53:56 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::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 26DAB1B2BA7 for ; Sun, 8 Nov 2015 04:53:56 -0800 (PST) Received: by qgea14 with SMTP id a14so42568343qge.0 for ; Sun, 08 Nov 2015 04:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dZZrWbIOy+HSClgshIb3FlVNJXh1WGBRYFuqJw4LzLc=; b=QKf0Ek4ov/fu+QLXsMYzMNC+J6gumY0FEcwkG6cXqpqhH1r5Ts3o8TWPS5ByopqrbO ziybjlLRTZaNsAot42RqMHxT3zz+M/48bXZDlRk3aoIKqyHMVD6rko+aZSvZIJ8E73in Vn9IgTn4/oyXC4+wdalK3oJywkbe6nr2d9hOBpaqprci+EDS4CLJNIjOKhQQriQFzcEZ u0rm4aLi3hoOYXMBZySQu4oL9CU0ka+dImBYvooo5K8uVO3WBVtepokoGSRCXndV9pbT 9gXbm8ndQgINT+QIjtKNpmfkfoxXXwVFryfp39EAPWzcsxUzlOAI+etCab2VUSaII1dM VOWQ== MIME-Version: 1.0 X-Received: by 10.140.21.133 with SMTP id 5mr22787556qgl.36.1446987235285; Sun, 08 Nov 2015 04:53:55 -0800 (PST) Received: by 10.140.85.102 with HTTP; Sun, 8 Nov 2015 04:53:55 -0800 (PST) In-Reply-To: <508F8973-D61A-49DF-A52B-CC8E8920C9E6@sn3rd.com> References: <544B0DD62A64C1448B2DA253C011414619276B8B23@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508F8973-D61A-49DF-A52B-CC8E8920C9E6@sn3rd.com> Date: Sun, 8 Nov 2015 18:23:55 +0530 Message-ID: From: Sarat G To: Sean Turner Content-Type: multipart/alternative; boundary=001a11c123ea27629b052406f899 Archived-At: Cc: "saag@ietf.org" , Rick Andrews Subject: Re: [saag] sha1 - have we more work to do? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 12:53:58 -0000 --001a11c123ea27629b052406f899 Content-Type: text/plain; charset=UTF-8 Thank you Sean. Regards, Sarat G On Fri, Nov 6, 2015 at 7:25 AM, Sean Turner wrote: > This is pretty new, but might a step in the right direction > http://datatracker.ietf.org/doc/rfc7630/. > > spt > > > On Nov 05, 2015, at 13:25, Sarat G > wrote: > > > > Hi Stephen, > > Recently I worked on SNMPv3. The SNMP auth protocol still uses HMAC SHA > 96 and HMAC MD5 96[RFC 2574]. > > > > Thank You. > > Regards, > > Sarat G > > > > > > > > On Thu, Oct 15, 2015 at 11:03 PM, Rick Andrews < > Rick_Andrews@symantec.com> wrote: > > Stephen, OCSP (RFC 6960) mandates SHA-1 for KeyHash, though the risk of > > using it here is probably very low. > > > > --------------- > > > > Message: 2 > > Date: Fri, 9 Oct 2015 14:25:40 +0100 > > From: Stephen Farrell > > To: "saag@ietf.org" > > Subject: [saag] sha1 - have we more work to do? > > Message-ID: <5617C054.1070207@cs.tcd.ie> > > Content-Type: text/plain; charset=utf-8 > > > > Hiya, > > > > While it may be still under submission, and not yet peer reviewed, I was > > just looking at [1,2] and wondered if we've still work to do to deprecate > > sha1 anywhere that we've not yet done. I know a lot of this was done > already > > but just wanted to check that we're good. > > > > Anyone know places where sha1 is still a should or must or where it's > still > > in widespread use despite no longer being a should or must? > > (No need to mention root stores in browser for that last though, as > that's a > > known issue and is I think already being tackled by browser > > makers.) > > > > I guess we can make a list and then figure out what to do if the list is > > non-empty. > > > > Cheers, > > S. > > > > [1] https://sites.google.com/site/itstheshappening/ > > [2] > https://sites.google.com/site/itstheshappening/shappening_article.pdf > > > > ------------------------------ > > > > > > > > > > _______________________________________________ > > 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 > > --001a11c123ea27629b052406f899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Sean.

Regards,
Sarat G


On Fri, Nov 6, 2015 at 7:25 AM, Sean Turner = <s= ean@sn3rd.com> wrote:
This = is pretty new, but might a step in the right direction http:= //datatracker.ietf.org/doc/rfc7630/.

spt

> On Nov 05, 2015, at 13:25, Sarat G <sarath.ginjupalli89@gmail.com> wrote:
>
> Hi Stephen,
> Recently I worked on SNMPv3. The SNMP auth protocol still uses HMAC SH= A 96 and HMAC MD5 96[RFC 2574].
>
> Thank You.
> Regards,
> Sarat G
>
>
>
> On Thu, Oct 15, 2015 at 11:03 PM, Rick Andrews <Rick_Andrews@symantec.com> wrote:
> Stephen, OCSP (RFC 6960) mandates SHA-1 for KeyHash, though the risk o= f
> using it here is probably very low.
>
> ---------------
>
> Message: 2
> Date: Fri, 9 Oct 2015 14:25:40 +0100
> From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
> To: "saag@ietf.org" <= ;saag@ietf.org>
> Subject: [saag] sha1 - have we more work to do?
> Message-ID: <5617C054= .1070207@cs.tcd.ie>
> Content-Type: text/plain; charset=3Dutf-8
>
> Hiya,
>
> While it may be still under submission, and not yet peer reviewed, I w= as
> just looking at [1,2] and wondered if we've still work to do to de= precate
> sha1 anywhere that we've not yet done. I know a lot of this was do= ne already
> but just wanted to check that we're good.
>
> Anyone know places where sha1 is still a should or must or where it= 9;s still
> in widespread use despite no longer being a should or must?
> (No need to mention root stores in browser for that last though, as th= at's a
> known issue and is I think already being tackled by browser
> makers.)
>
> I guess we can make a list and then figure out what to do if the list = is
> non-empty.
>
> Cheers,
> S.
>
> [1] https://sites.google.com/site/itstheshappeni= ng/
> [2] https://sites.google.c= om/site/itstheshappening/shappening_article.pdf
>
> ------------------------------
>
>
>
>
> _______________________________________________
> 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


--001a11c123ea27629b052406f899-- From nobody Sun Nov 8 05:04:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C68A1B2BDD for ; Sun, 8 Nov 2015 05:04: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGSyzBzXEhH4 for ; Sun, 8 Nov 2015 05:04:34 -0800 (PST) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D4C1B2BDC for ; Sun, 8 Nov 2015 05:04:34 -0800 (PST) Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id D82696D735; Sun, 8 Nov 2015 08:04:32 -0500 (EST) To: saag@ietf.org References: <563DFCFB.8090405@openca.org> From: ianG Message-ID: <563F485F.8@iang.org> Date: Sun, 8 Nov 2015 13:04:31 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563DFCFB.8090405@openca.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 13:04:36 -0000 On 7/11/2015 13:30 pm, Massimiliano Pala wrote: > The idea is very simple: provide specifications for interfaces to > cryptographic libraries. In my experience, this is not a good idea. I do agree that people are going to do it anyway, because the world of developers is built to create new and better and more standard APIs, but doing it is just their learning experience. Some reasons... because it's Sunday. * In theory there is a notion that forcing one good API on everyone will improve their code security, but in practice there are so many ways to shoot yourself in the foot that it might not be able to show a benefit. * The API that is wanted tends to be different with every project. Every project has a different threat model. There is a myth that the SSL threat model is kind of useful for other projects, and this has driven a lot of API design, for example the certificates, but the SSL threat model isn't even coherent within its own domain. Borrowing it without thought is just security negligence because most projects are based on datagrams [0], so even their architecture mitigates against the open continuous reliable pipe design that SSL blithely inherits from TCP without question. * In practice, what people need is a much higher level API than is normally provided. For an example of this have a look at DJB's cryptobox. After much hacking I ended up with the same approach in my code, there is no middle level API, there is instead many similar silos in a pattern I call BusyBee [1]. * In the alternate, there is an extreme failing from the API approach which is epitomised by the Java JCE. In this monstrosity, not only can you be unsure which library you're getting, you can't really be sure you're even "allowed" to use crypto. So we get this continual user configuration nightmare. From a security pov, JCE is unauditable so we're in this weird position of using 256bit strength crypto but we can only use it in middling applications where we don't mind if it all gets perverted by the oracle-in-the-muddle attack. * And that's without looking at the overall failure of the API to keep up with modern times, and the failure to deprecate and improve ciphersuites, and the complexity of figuring out what is going on through layers like mobile phones: application -> manufacturer -> Android -> google -> oracle -> Java JCE. Yes, there have been several exploits / failures that can be purely attributed to supply chain madness. And money was lost, in the Bitcoin world, where they blithely just used this crypto stuff they were given and it turned out to be flawed. * One good argument for an API is that the library meets it and therefore that code doesn't have to be written by the programmer. This is good. But this says nothing about the level that is appropriate. iang [0] I'm precisely saying datagrams here, not UDP. [1] because it does everything and buzzes a lot getting it done. From nobody Sun Nov 8 06:54:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018FB1B2E2A for ; Sun, 8 Nov 2015 06:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdzGf3pq4vZh for ; Sun, 8 Nov 2015 06:54:05 -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 C23AD1B2E2D for ; Sun, 8 Nov 2015 06:54:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01FE3BE47; Sun, 8 Nov 2015 14:54:03 +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 A2S6eH1cZ5hH; Sun, 8 Nov 2015 14:54:01 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.22.174]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D6DD8BE35; Sun, 8 Nov 2015 14:53:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1446994441; bh=IxO8eD8EUyFkIxYUyoHNY2IJlF+pSVvWF7FOcKiRfaY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=S+sbaPC6oKF5VxJubqeo7DxzOnySVWPjqAMShwoPM8MAcVUJWgxUd1hn+TY9jJH7P OIshZ6HusM97AzPE807aCFvJQl+dg2s7yYhBQorjHfky7BmykXUlRaDfBlnHn6VDoj O7POYOo+gl1mjoFv+iAXgBp2dsG/YHcrFUghPoNc= To: Massimiliano Pala References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <563F6200.5040107@cs.tcd.ie> Date: Sun, 8 Nov 2015 14:53:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563EDFC6.2050102@openca.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 14:54:08 -0000 Hi Max, I've no opinion now as to whether the IETF ought seek consensus on the specifics of an API such as you propose. Mainly, I'd be for doing it, if the API is good and we're not stepping on anyone's toes, and against dong it if the API is not good and causes liaison issues. (Yes, that's not an exhaustive characterisation, deliberately:-) I would not however support the IETF formally starting out on such work with a blank sheet of paper. I'm pretty sure we'd end up with an output that'd make everyone unhappy after loads of effort. So, I'd suggest that if you want to pursue this, best would be to get interested folks working alongside (but outside) the IETF and write the code you want and then propose that the resulting API be standardised. "Alongside (but outside)" could mean various things but what your web page indicates seems like a fine one of those. So, if you stick with that approach, I'd say come back when you think the specs at [1] are ready. I'd also note that Kathleen's been doing good work on getting some of the PKCS series under IETF change control. But I think the plan for PKCS#11 was to have that done in OASIS, [2] so I'd suggest that chatting with those folks would be sensible, if you've not already. Cheers, S. [1] https://github.com/SICA-WG/specs [2] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 From nobody Sun Nov 8 08:29:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F405B1A02F1 for ; Sun, 8 Nov 2015 08:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWTFjzKmAYir for ; Sun, 8 Nov 2015 08:29:54 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03A931A035F for ; Sun, 8 Nov 2015 08:29:53 -0800 (PST) Received: from [192.168.10.249] ([80.92.121.146]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MdaCy-1a5Gzb20QW-00PN4P for ; Sun, 08 Nov 2015 17:29:51 +0100 To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <563F787D.7010509@gmx.net> Date: Sun, 8 Nov 2015 17:29:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aE4SqrBkXHKv9ktgKfV1iqeH282VSmCSw" X-Provags-ID: V03:K0:crLv5qyGr1kctmOh2nLFmKnNQWWafRNLig8mSBgRXB4u7qw46A2 Sj1GUsRDZ9Ajw+8U6IauKyHwwva4OMgDGSPti4GR0qy/OKqElHIfNpDDkxBnPsmbjj1wxsZ tqTnd2OaU1PtLqts4gR2zIQem9ucWMbkepRXJJHX7PqlmSeMf7/LugREr3Vx2Yix/aJPb18 bJEU7Fq//eBYi3+DQnn2A== X-UI-Out-Filterresults: notjunk:1;V01:K0:PV6YSOITyzs=:bzPzOsgncY6sFPC6mTa+zw UXeU928IBGnpqqC+1D8A733E7HP/Hho6N2yXFopeauTRU9wlsiSZQA5K9EH5vEaByIWyXflP6 ZC3F4TqceuxZXU7tGJuOmNp2e3WI0t+Z2ewjR0UGJg5d0jWHYN8BuQtfV2EI8PXmJx7eh7MYf c2N0Io76GYowqQ5kiNtAOkZhQbqpcc4ZcOcVKbsrpVfO/6ypfa0fvaXTbNNk2sHlSvOgK7BiZ bhN/OhvRaEkOEt2obo9si8wI68QV4O4rqG6/rnjp7taB1L4fdfPEaGEcgmmjqqPzOUS7cqYzR ujWeQ76gMd2dTJF4zChAYd0SRFyI6V/eb72DBsXAuFyaHeIe4gaUBqF5czxT38tulGd5fOc2n kqrJBhSTjVs4daK5AYEGQMyOtsNiWSYjHzAMbOKdEnS8OXn8M9TXXAJyFGlxJtwhT3T7qCKfb 36vkMjer/U1N1HVU6/7YdQDIh9HAR73dSUuwiqxVt4fmkXJNJF3wQLyWyvXb0OGony98i7g8m AdUVIh+/4SDFHujeLw6QFuiRQGjAR0iR87eWB56HXcXBS2YHttzyFksmb1cXEEO5I3FGOP8yQ VWmuz15ewYMYEAmjYvR+RY0m1ZYxHRO85/aa0zt3iGuURE1XCX8Zrsj8JIUhtESWdPZhhfGMi dv5ca/ujeBjwqGBIFg/4tBDIXQSjUETzsgzpO4gf2re/VmMQE3cy9tksGKp0+TOpIjsjJTM5k yhrlY4zjvifJys/Fq5K+T8raouV1ImsmJHMe3HM9hhmN6Y/ST96vPs7KE40= Archived-At: Subject: [saag] OAuth WG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 16:29:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aE4SqrBkXHKv9ktgKfV1iqeH282VSmCSw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The OAuth working group meet on Thursday afternoon. Since Prague we published 2 new RFCs, * Token introspection, and * Proof Key for Code Exchange (PKCE) by OAuth Public Clients During the first part of the meeting we focused on discussing our remaining work items, in particular the proof-of-possession (PoP) work. Two documents related to our PoP agenda items have been submitted to the IESG for publication recently and we will spend the next two months with the completion of this work. During the second part of the meeting we talked about rechartering and had various presentations related to the following areas: - Native Apps - Security Extensions & Fixes - API Management / Resource Set Registration - JWT Claims - Device Flow - Discovery During the meeting interest was gauged and the rechartering discussions will continue on the mailing list since various participants requested more information. We expect to see several new drafts to be submitted. --aE4SqrBkXHKv9ktgKfV1iqeH282VSmCSw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWP3h+AAoJEGhJURNOOiAt4PwIAJ+1ImA+O+n0aIkp3pyTwwpn oeUD+5oDCV5Y6m94fc9xKNifg7ikVui4o7ccMKcJbwlPpuupXFqPcX8Pq7fhnRbf sTk433o65sqZvgWf6lsKHl3JWGtdwxg2uhLYac+T7Y1I3cGBI/2H2uRXm2vdsXIP MSD2o8ooRivwgHIznhkgkFirHMQv90XsczxKXQ+zIiEohAgxKAhsIB/FevATMRt4 JGk0nXSNre+xpIdMxtqyMB5+2Z8qPLdi9V1gXBK7MBU63ic2hsWqmuxQgCpyru9z jc0LjEAwRIC1qjNxFAhZc3ubTevgQCpgwwloXaKm6QjMJXX7N5xtsKMMJE8oqTk= =6zu7 -----END PGP SIGNATURE----- --aE4SqrBkXHKv9ktgKfV1iqeH282VSmCSw-- From nobody Sun Nov 8 16:27:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408B81B53DC for ; Sun, 8 Nov 2015 16:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 h-CTkYUIvpFt for ; Sun, 8 Nov 2015 16:27:20 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::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 A31B91B53DA for ; Sun, 8 Nov 2015 16:27:20 -0800 (PST) Received: by ykek133 with SMTP id k133so240864164yke.2 for ; Sun, 08 Nov 2015 16:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari_net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e4ehESaJTuPb5QwhR3sF0BYYC+XOPD7YGEuPo1O7Omg=; b=2RCPpsur1fEZJUhKkftroEGFuD/LbV4X1Lwy0JPLyxpANAVHX4n3azPdhx5qO04JRV 90HTlz3SBgBqqkuUO80cok0FiGKV/EdE6GOwnhqqHDRFTkKSZGhFQ/4lzDFfKsngyHWo ri+tLyzVgRUMT67xDW+o33Fyfq8YjushkKdK9bW9TyHM6LBZaeAGc1RL+oZhwrVIWfJS GsufRemmD1o4MY09jFGq+Be2D2uRIJkgtcz9SM7m7QoiMud0EspdiuF2B+MZSna/eggf rezsxnsX00F0YK5XFA2rFRyHFLB1SpqtE2DtrHNqifhsDTU508XycGG+Y+YGaJqydKLp f0AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=e4ehESaJTuPb5QwhR3sF0BYYC+XOPD7YGEuPo1O7Omg=; b=jPuFwkXVdNAyXPxbtmg94QbHNn5fmNE5Dy6eTZOIfoK9HKErwTvnsT8pjwFTTZXhP7 Oim1DQ2HrsZzkRt6q7LhJ1EoJ19pOx+6lFzBMZDyXjbi1BKP9I62EHX4Lco6Jl4fHhf0 nByhpehZ13/y80VbDWjM4rGLIMaJfCkh15QZtl77NFZzKG2YjNDdeZNWendpPPYUBUBD PLJYJkv7EKK8taVk6gXXQH6hBg3r6DjKgrUKDqnkjAv1bTsMkx744ha5gNFr2TcG3fnf seYoHSaT3byUjZue3D/TE8oMfyPSNBg46fT8Al/Szb6LozfM4Tvzobss0316yUugrF2a 7gjg== X-Gm-Message-State: ALoCoQkrj1OZACNrtR8p/JaQ5nj6n6XtjacCuV32JC5x7ImRGvqt/oxA70hrOQxS+hN2OjGgBKXm MIME-Version: 1.0 X-Received: by 10.129.57.133 with SMTP id g127mr20219883ywa.105.1447028839682; Sun, 08 Nov 2015 16:27:19 -0800 (PST) Received: by 10.37.202.11 with HTTP; Sun, 8 Nov 2015 16:27:19 -0800 (PST) In-Reply-To: References: <20150826170138.GB9021@mournblade.imrryr.org> <55E028E0.6080803@restena.lu> Date: Mon, 9 Nov 2015 09:27:19 +0900 Message-ID: From: Warren Kumari To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 00:27:22 -0000 On Sat, Aug 29, 2015 at 4:13 AM, Christian Huitema wrote: > On Friday, August 28, 2015 2:25 AM, Stefan Winter wrote: >> To: saag@ietf.org >> Subject: Re: [saag] Would love some feedback on Opportunistic Wireless >> Encryption >> >> Hi, >> >> > You are right that there will be some initial legacy issues -- but if >> > we can convince Windows 10 Mobile, Apple iOS, and Android willing to >> > include support (which seems likely, "support" is trivial - basically >> > 1: try the SSID as the passphrase and 2: don't bother showing a lock >> > icon) >> >> Or, for wireless sniffing kit of your choice: >> >> 1) try to decrypt with the SSID as the password >> 2) win! > > It is a bit more complicated than that, but not much. With WPA2, the traf= fic is not directly encrypted with the password, but instead with a key der= ived from the password, the SSID, an Access Point nonce, and a Station nonc= e. Even if the password is shared, each client uses a different set of nonc= e, and thus a different key. However, the nonce are transmitted in clear-te= xt during the initial exchange. That means the attack goes as: > > 1) Capture the initial exchange between Station and Access point, and rem= ember the nonce. > 2) Assume that the SSID is the password and try to derive the per station= key using the nonce. > 3) Win! > > This is in fact the main limitation to Warren's approach. The proposed OW= E system will still be vulnerable to passive listener attacks, and is thus = not much of an improvement over open networks. > > Note that this is also a limitation of the "public password" approach, as= in "ask the password to the bartender." We can hypothesize that mass surve= illance systems will quickly build a database linking networks, SSID and pu= blic passwords. After all, the initial WPA2 exchange carries authentication= codes that are the hash of the nonce and the password, which trivially ena= bles dictionary attacks. That means the procedure will be: > > 1) Capture the initial exchange between Station and Access point, and rem= ember the nonce. > 2) Retrieve the password associated to the SSID from the database. > 3) Derive the per station key using the nonce. > 4) Win! > > Thinks would be different if instead of just sending the nonce in clear t= ext the WPA2 exchange used some variation of Diffie-Hellman or EKE. Attacke= rs would need to move from "passive listening" to "actively implement MITM = attack," and we believe that might curtail mass surveillance efforts. But t= hat's not the case. ... and a quick update (which I thought I'd sent earlier, but apparently not) - when we wrote the initial document, we were well aware of the issues with the 4 way handshake, but decided to write the document in the IETF context anyway. This was because I figured that a better than nothing approach was, well, better than nothing. We were aware that the IEEE was the correct layer to get this done, but, well, I don't participate there much, and figured that it would be a hard / very slow process. Dan Harkins (who most of you know), is an IEEE regular, has nicely rewritten this into IEEE language, and is getting strong interest / making progress there. This basically does what everyone has been suggesting (and I'd originally wanted to do, but couldn't) -- a public key exchange between the AP and STAtion (think DH). This is obviously much much less hacky than the "just pretend that the user typed the SSID as the passphrase, and don't show any indications (to avoid having the user believe that they have "security")". W > > -- Christian Huitema > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Nov 9 12:45:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC19C1B83FC for ; Mon, 9 Nov 2015 12:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.966 X-Spam-Level: X-Spam-Status: No, score=0.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=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 P4TkBsxCpf9g for ; Mon, 9 Nov 2015 12:45:26 -0800 (PST) Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7C61ACCEB for ; Mon, 9 Nov 2015 12:45:25 -0800 (PST) Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id 4858E41FBD for ; Mon, 9 Nov 2015 21:45:08 +0100 (CET) Received: from [22.187.216.95] (unknown [172.56.22.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id 8E9F618A08DA for ; Sun, 8 Nov 2015 06:56:01 -0500 (EST) Content-Transfer-Encoding: 7bit Content-Type: multipart/signed; boundary=Apple-Mail-43C9997B-502E-4591-9102-541AF6EF1990; protocol="application/pkcs7-signature"; micalg=sha1 From: "Dr. Pala" Mime-Version: 1.0 (1.0) Date: Sun, 8 Nov 2015 06:56:00 -0500 Message-Id: <704A9304-1081-4CD7-B566-27DD7BAA41E6@openca.org> References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> <090207A0-65F1-4605-B19B-AF0DDFBF61E1@vigilsec.com> In-Reply-To: <090207A0-65F1-4605-B19B-AF0DDFBF61E1@vigilsec.com> To: saag@ietf.org X-Mailer: iPhone Mail (13B143) Archived-At: Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 20:45:30 -0000 --Apple-Mail-43C9997B-502E-4591-9102-541AF6EF1990 Content-Type: multipart/alternative; boundary=Apple-Mail-BC41F76D-B408-49A1-96C8-54394942561A Content-Transfer-Encoding: 7bit --Apple-Mail-BC41F76D-B408-49A1-96C8-54394942561A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Russ, Absolutely. I think that there are a number of high-level concepts that are g= oing to be included in the API definition and the underlying implementation c= an leverage what works today for hardware devices (e.g. PKCS#11, PKCS#12, MS= -CAPI store, etc.). I totally agree that having seamless integration between software and hardwa= re stores would be a win-win situation. Standardizing this interface would a= lso be important. Cheers, Max > On Nov 8, 2015, at 12:44 AM, Russ Housley wrote: >=20 > Max: >=20 > Wouldn't the ideal API be the same for software libraries and hardware dev= ices? Having the application seamlessly work regardless of the manner that t= he key is stored would be a big win for application developers. To this end= , some people use PKCS#11 as an interface to software. >=20 > Russ >=20 >=20 >> On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote: >>=20 >> Hi Jaroslav, >>=20 >> thanks for the feedback. I do understand your position - however, I do di= sagree with the premises. PKCS#11 is a successful standard when it comes to h= ardware interfaces. However, since its design was targeted to standardizing i= nterfaces for hardware devices, it does not always provide the easiest / bes= t approach when it comes to applications. Therefore much work is required to= fill those gaps (only using PKCS#11 calls does get you only that far). >>=20 >> This said, I think that learning from the limitations of the solutions we= have today is an important step towards specifying the scope of the propose= d work. Maybe we will end up having a similar API or we might provide an hig= her level one or, again, a simplified version of it. In my opinion, all the s= olutions you are listing here try to address a real pain by using the only s= tandard API we have today. A commendable effort, but not what I am proposing= . >>=20 >> Another important aspect that is usually under-estimated when it comes to= crypto APIs is usability. I personally think that PKCS#11 is not a great ex= ample from this point of view and, AFAIK, people that have developed against= it have often resorted to develop their own abstraction layer on top of it.= Moreover, most of the times, developers need to use other interfaces to dea= l with all extra details when it comes to, for example, dealing with certifi= cates processing (e.g., chain validation, etc.). >>=20 >> This is my personal opinion, of course, and I do not want to start a disc= ussion about if this work is needed or not here (especially because I have a= lready been told that IETF is not interested in this work). I think there is= much to be done and I am happy to discuss all these aspects and collaborate= with as many experts (who practically have felt the pain when developing ap= plications) as possible. If you feel that this is still a pain point today, p= lease join the effort. >>=20 >> Thanks again for the feedback, >>=20 >> Cheers, >> Max >>=20 >>=20 >>> On 11/7/15 8:59 AM, Jaroslav Imrich wrote: >>> Hi Max, >>>=20 >>> I believe PKCS#11 [0] already provides those benefits, it is widely adop= ted by both commercial and open-source projects and it works not only for ha= rdware but also for pure software crypto implementations - for example SoftH= SM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top o= f MS CAPI. What would be the benefits of the new API over PKCS#11? >>>=20 >>> Regards, Jaroslav >>>=20 >>> [0] https://www.oasis-open.org/committees/pkcs11/ >>> [1] https://www.opendnssec.org/softhsm/ >>> [2] http://thewalter.net/git/cgit.cgi/p11-capi/ >>>=20 >>>=20 >>>> On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala = wrote: >>>> Hi all, >>>>=20 >>>> I am not sure this is the right place to write this e-mail, but I hope i= s. At the meeting I spoke with several people about an idea I had some time a= go but never landed at IETF. Since I got positive feedback and suggestion to= post the idea to this list to see if others might be interested, here's the= summary e-mail. >>>>=20 >>>> The idea is very simple: provide specifications for inter= faces to cryptographic libraries. The basic idea is to provide an API that d= ifferent vendors can implement on top of their libraries to provide a standa= rd interface for applications. If successful, an application could make use o= f OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that= interface without having to re-write the crypto-related code. This allows f= or portability (wider adoption of crypto-enabled applications), code/modules= re-usability, and the possibility for applications to switch between vendor= s (e.g., switching to a better crypto library or dismissing a library that h= as shown vulnerabilities). >>>>=20 >>>> Although I received positive feedback about the idea (I know, it has be= attempted in the past.. ), I was never able to get the green light to proce= ed with a proposal for IETF (unfortunately the answer was always "we don't d= o APIs" ... which, actually, it is not true), so I decided to move forward a= nyway, since it is a real pain that needs to be solved. If the IETF will lik= e to pick up the work in the future, great. If not, we'll solve the problem a= nyway :D >>>>=20 >>>> If you are interested in participating in the effort (e.g., writing spe= cs, participating in the discussion, provide feedback, or writing code) plea= se contact me and we'll take it from there. I wrote a couple of pages today (= very quick and dirty work for now.. so.. don't judge!), but I hope we'll be a= ble to gather momentum and work together on this. The website is reachable a= t: >>>>=20 >>>> http://cryptoapi.openca.org/ >>>>=20 >>>> Last but not least - I am starting also another project that targets th= e use of SYMMETRIC crypto by providing support for encryption at rest. This l= ibrary will provide support for storing encrypted data, signed (hmac) data, s= ymmetric keys, and symmetric keys bundles (stack of keys) in s= uch a way that it is simple to use (e.g., dealing with symmetric crypto is h= ard for the average developer since not much support, outside TLS, is provid= ed). By defining a simple high-level API for symmetric crypto we want to fil= l the gap and, hopefully, increase the use of crypto also in those environme= nt where asymmetric is not an option (e.g., latency constraints). The idea i= s to actually write a standard for symmetric crypto ... "at rest". >>>>=20 >>>> Also for this project, please contact me directly (I still do not have p= ages for this project for various reasons - most importantly I still have to= see if I get to open source what I did for my employer of if we have to sta= rt from scratch) at this e-mail address. >>>>=20 >>>> Happy Security Everybody! >>>>=20 >>>> Cheers, >>>> Max >>>>=20 >>>> P.S.: Other items on the back burner that I would welcome contributions= to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI R= esource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (= Discovery) System (PKS). >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --Apple-Mail-BC41F76D-B408-49A1-96C8-54394942561A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Russ,

Absolutely. I think that the= re are a number of high-level concepts that are going to be included in the A= PI definition and the underlying implementation can leverage what works toda= y for hardware devices (e.g. PKCS#11, PKCS#12, MS-CAPI store, etc.).

I tota= lly agree that having seamless integration between software and hardware sto= res would be a win-win situation. Standardizing this interface would also be= important.

Cheers,<= div>Max

On Nov 8, 2015, at 12:44 AM, Russ Housley &= lt;housley@vigilsec.com> wrot= e:

Max:

Would= n't the ideal API be the same for software libraries and hardware devices? &= nbsp;Having the application seamlessly work regardless of the manner that th= e key is stored would be a big win for application developers.  To this= end, some people use PKCS#11 as an interface to software.

Russ


On Nov 8, 2015, at 12:38= AM, Massimiliano Pala wrote:

<= blockquote type=3D"cite"> =20 =20
Hi Jaroslav,

thanks for the feedback. I do understand your position - however, I do disagree with the premises. PKCS#11 is a successful standard when it comes to hardware interfaces. However, since its design was targeted to standardizing interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to applications. Therefore much work is required to fill those gaps (only using PKCS#11 calls does get you only that far).

This said, I think that learning from the limitations of the solutions we have today is an important step towards specifying the scope of the proposed work. Maybe we will end up having a similar API or we might provide an higher level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try to address a real pain by using the only standard API we have today. A commendable effort, but not what I am proposing.

Another important aspect that is usually under-estimated when it comes to crypto APIs is usability. I personally think that PKCS#11 is not a great example from this point of view and, AFAIK, people that have developed against it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, developers need to use other interfaces to deal with all extra details when it comes to, for example, dealing with certificates processing (e.g., chain validation, etc.).

This is my personal opinion, of course, and I do not want to start a discussion about if this work is needed or not here (especially because I have already been told that IETF is not interested in this work). I think there is much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who practically have felt the pain when developing applications) as possible. If you feel that this is still a pain point today, please join the effort.

Thanks again for the feedback,

Cheers,
Max


On 11/7/15 8:59 AM, Jaroslav Imrich wrote:
Hi Max,

I believe PKCS#11 [0] already provides those benefits, it is widely adopted by both commercial and open-source projects and it works not only for hardware but also for pure software crypto implementations - for example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What would be the benefits of the new API over PKCS#11?

Regards, Jaroslav


On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <director@openca.= org> wrote:
Hi all,

I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at:

    http://cryptoapi.open= ca.org/

Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS).


_______________________________________________
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<= br>

= --Apple-Mail-BC41F76D-B408-49A1-96C8-54394942561A-- --Apple-Mail-43C9997B-502E-4591-9102-541AF6EF1990 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFQjCCBT4w ggQmoAMCAQICEQDrBY3cY3XzPSAQqnn+iw5pMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTUxMTA4MDAwMDAwWhcNMTYxMTA3MjM1 OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eub3JnMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArfcvp27noyzBN+WYa2H6Vh/+Ok8G8QSvjWhszqn4rqKMizRbKWxL grE92Em9bV6XCxeGcVYX30PZzF+VHwwjo9yxoVkOOjYxTIpjA17TJBH2V1veMmtJhCg6L/KpGXSB 8VXxK0pQcYK8shpr7/pR8NSfQQhS9639Ib/oBF7JzZjmgFPfLgavyzF7zQq3GBsSQpicITYwtpnI RG78vUK/KE9Cv0UgKMULDgOIvQRbx/In1jvPD5Aj1gBm6nFAG0iPFwfW2zLQVePSqwXzxCBmzKCu ymxDv39tSRjJkTPWfCZAM/NzLhI411sytcKEXMi/Ud0/iF+7d3KeSwKQUPoBdQIDAQABo4IB8TCC Ae0wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFJoTLU8DzRcG2QKK b0acLDP8n3aIMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0f BFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0 aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYB BQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAeBgNVHREEFzAVgRNkaXJlY3RvckBvcGVuY2Eub3JnMA0GCSqGSIb3DQEBCwUAA4IB AQBzIbk8Y+p0XPyIv1/q+Pt+BKpK7wY2JwHM9XCsoMbZnz5IfdQNapELTH5NRSfsZ+DCjvNrkatC 5az3Gn3FLRdPyRlKGWVirgrwnjHTOVVfLyqmNeV2Z8FbtAJFRbY/XJA+GJH680kL1PcL99SvJIVr ZK8V0a0fr6tLjymnLPXpjYaYkACIOuUdXrlaHRydBxwsQhTIwxkHsYNpx64o3nF64Wx5LMyqkQmY FDMV91yO3QqN6tzgTgQiw8+RQm5mXbDvoeFjZoq18pM20AI+aX34ZottOfNPRKuEE/AP7h08x7k1 +AUYkcRjYXFj/SJVc2eeGI0wXHbVwB4tFkZMZ7OzMYIDxjCCA8ICAQEwgbEwgZsxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOsFjdxjdfM9IBCqef6LDmkwCQYFKw4D AhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTA4 MTE1NjAwWjAjBgkqhkiG9w0BCQQxFgQU2VVoTkE8ofKbug0LpGSRVw0q3rEwgcIGCSsGAQQBgjcQ BDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9E TyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA6wWN 3GN18z0gEKp5/osOaTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOsFjdxjdfM9IBCqef6LDmkwDQYJKoZIhvcNAQEBBQAE ggEAMzDFsZizaizaTxObOY0QKy4gV1ty+rRWTyKpDOlW+qj3S+izY2STKD+vB64n3Vt4VBysJnLt h6iUxKSWp4/HGTDbGwj/XODFKdaDEkmY7m2fG0TfAUdoA9unWRb7sMjpLVIpn7ypjPZTnY9Z+L/D gHuxKBjkZMCRBRt8KXZPPf05MOP6i3LsDnkwfw5SHQYZptUYpyF1OVLjl724Sw0LyqTdvbMODWBg Zm1thVnvU787VAu0Ql/CfyxwrUjy2mCGBJBBPAzbEF3h+ZfCQu3lsO6DsnvpkJMxveetC78rhavg kfcr2E7/JlITW3lo1GvEm3vJlqn0eMCxWHC63p3JRwAAAAAAAA== --Apple-Mail-43C9997B-502E-4591-9102-541AF6EF1990-- From nobody Mon Nov 9 12:53:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF081B8422 for ; Mon, 9 Nov 2015 12:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEhKoz7sDvSc for ; Mon, 9 Nov 2015 12:53:08 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D141B842A for ; Mon, 9 Nov 2015 12:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20691; q=dns/txt; s=iport; t=1447102388; x=1448311988; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oVkfuG/Ra4hvede8AcyYLJXRmu28IAYXNiGDrfMXK0E=; b=AZlZIJm4j3s3udZxtz/bips9NPGEJyTTq19o0Hc6wtXkaYqAPyQKKFQK zAr9XBT0KilXYfAdVz+ALACKPCP6SNOwMeHrY03+k47WgHJoBs6BB8zve G8fv51AN/2u0KGePmBhRgSQ0OTaRzH5PaGP1qKw7IWLJgT4wLzHMc6MVv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBNB0FW/5ldJa1egztTbwa+OAENg?= =?us-ascii?q?WMXAQmCPoMxAoFFOBQBAQEBAQEBgQqENgEBBAEBAWgCAQsQAgEIPwcnCxQRAgQ?= =?us-ascii?q?OBRsDiBANwWUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYiGSBaIEGhQgRgwuBFQWSZ?= =?us-ascii?q?4NhAYUdiAmBW0mDd5I4g3EBHwEBQoIRHYFWcoQeJRyBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,267,1444694400"; d="scan'208,217";a="206071604" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2015 20:53:07 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tA9Kr7TS007131 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2015 20:53:07 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 Nov 2015 14:53:06 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Mon, 9 Nov 2015 14:53:06 -0600 From: "Max Pritikin (pritikin)" To: "Dr. Pala" Thread-Topic: [saag] Standard Crypto API + Symmetric Crypto At Rest Thread-Index: AQHRGWCUJb8HXlNa/Ey4CCg6MKtnrp6Q+vsAgAEGKwCAAAGggIAAZ+wAgAIodgA= Date: Mon, 9 Nov 2015 20:53:06 +0000 Message-ID: References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> <090207A0-65F1-4605-B19B-AF0DDFBF61E1@vigilsec.com> <704A9304-1081-4CD7-B566-27DD7BAA41E6@openca.org> In-Reply-To: <704A9304-1081-4CD7-B566-27DD7BAA41E6@openca.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.14] Content-Type: multipart/alternative; boundary="_000_D617B084E1D24A0EAD7A225BC8AD3400ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 20:53:12 -0000 --_000_D617B084E1D24A0EAD7A225BC8AD3400ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "seamless integration between software and hardware stores" +1 Many times we work with software that assumes different interfaces and, per= haps more insidious, assumes that keys are always extracted from software s= tores to be used in memory. (For example instead of leveraging a crypto eng= ine interface w/in their TLS library they instead pass the raw keys into th= e library and expect it to be used locally). - max On Nov 8, 2015, at 4:56 AM, Dr. Pala > wrote: Hi Russ, Absolutely. I think that there are a number of high-level concepts that are= going to be included in the API definition and the underlying implementati= on can leverage what works today for hardware devices (e.g. PKCS#11, PKCS#1= 2, MS-CAPI store, etc.). I totally agree that having seamless integration between software and hardw= are stores would be a win-win situation. Standardizing this interface would= also be important. Cheers, Max On Nov 8, 2015, at 12:44 AM, Russ Housley > wrote: Max: Wouldn't the ideal API be the same for software libraries and hardware devi= ces? Having the application seamlessly work regardless of the manner that = the key is stored would be a big win for application developers. To this e= nd, some people use PKCS#11 as an interface to software. Russ On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote: Hi Jaroslav, thanks for the feedback. I do understand your position - however, I do disa= gree with the premises. PKCS#11 is a successful standard when it comes to h= ardware interfaces. However, since its design was targeted to standardizing= interfaces for hardware devices, it does not always provide the easiest / = best approach when it comes to applications. Therefore much work is require= d to fill those gaps (only using PKCS#11 calls does get you only that far). This said, I think that learning from the limitations of the solutions we h= ave today is an important step towards specifying the scope of the proposed= work. Maybe we will end up having a similar API or we might provide an hig= her level one or, again, a simplified version of it. In my opinion, all the= solutions you are listing here try to address a real pain by using the onl= y standard API we have today. A commendable effort, but not what I am propo= sing. Another important aspect that is usually under-estimated when it comes to c= rypto APIs is usability. I personally think that PKCS#11 is not a great exa= mple from this point of view and, AFAIK, people that have developed against= it have often resorted to develop their own abstraction layer on top of it= . Moreover, most of the times, developers need to use other interfaces to d= eal with all extra details when it comes to, for example, dealing with cert= ificates processing (e.g., chain validation, etc.). This is my personal opinion, of course, and I do not want to start a discus= sion about if this work is needed or not here (especially because I have al= ready been told that IETF is not interested in this work). I think there is= much to be done and I am happy to discuss all these aspects and collaborat= e with as many experts (who practically have felt the pain when developing = applications) as possible. If you feel that this is still a pain point toda= y, please join the effort. Thanks again for the feedback, Cheers, Max On 11/7/15 8:59 AM, Jaroslav Imrich wrote: Hi Max, I believe PKCS#11 [0] already provides those benefits, it is widely adopted= by both commercial and open-source projects and it works not only for hard= ware but also for pure software crypto implementations - for example SoftHS= M [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top o= f MS CAPI. What would be the benefits of the new API over PKCS#11? Regards, Jaroslav [0] https://www.oasis-open.org/committees/pkcs11/ [1] https://www.opendnssec.org/softhsm/ [2] http://thewalter.net/git/cgit.cgi/p11-capi/ On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <director@openca.org> wrote: Hi all, I am not sure this is the right place to write this e-mail, but I hope is. = At the meeting I spoke with several people about an idea I had some time ag= o but never landed at IETF. Since I got positive feedback and suggestion to= post the idea to this list to see if others might be interested, here's th= e summary e-mail. The idea is very simple: provide specifications for interfaces to cryptogra= phic libraries. The basic idea is to provide an API that different vendors = can implement on top of their libraries to provide a standard interface for= applications. If successful, an application could make use of OpenSSL, MS-= CAPI, Cryptlib, or any other crypto library that provides that interface wi= thout having to re-write the crypto-related code. This allows for portabili= ty (wider adoption of crypto-enabled applications), code/modules re-usabili= ty, and the possibility for applications to switch between vendors (e.g., s= witching to a better crypto library or dismissing a library that has shown = vulnerabilities). Although I received positive feedback about the idea (I know, it has be att= empted in the past.. ), I was never able to get the green light to proceed = with a proposal for IETF (unfortunately the answer was always "we don't do = APIs" ... which, actually, it is not true), so I decided to move forward an= yway, since it is a real pain that needs to be solved. If the IETF will lik= e to pick up the work in the future, great. If not, we'll solve the problem= anyway :D If you are interested in participating in the effort (e.g., writing specs, = participating in the discussion, provide feedback, or writing code) please = contact me and we'll take it from there. I wrote a couple of pages today (v= ery quick and dirty work for now.. so.. don't judge!), but I hope we'll be = able to gather momentum and work together on this. The website is reachable= at: http://cryptoapi.openca.org/ Last but not least - I am starting also another project that targets the us= e of SYMMETRIC crypto by providing support for encryption at rest. This lib= rary will provide support for storing encrypted data, signed (hmac) data, s= ymmetric keys, and symmetric keys bundles (stack of keys) in such a way tha= t it is simple to use (e.g., dealing with symmetric crypto is hard for the = average developer since not much support, outside TLS, is provided). By def= ining a simple high-level API for symmetric crypto we want to fill the gap = and, hopefully, increase the use of crypto also in those environment where = asymmetric is not an option (e.g., latency constraints). The idea is to act= ually write a standard for symmetric crypto ... "at rest". Also for this project, please contact me directly (I still do not have page= s for this project for various reasons - most importantly I still have to s= ee if I get to open source what I did for my employer of if we have to star= t from scratch) at this e-mail address. Happy Security Everybody! Cheers, Max P.S.: Other items on the back burner that I would welcome contributions to = are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Res= ource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (= Discovery) System (PKS). _______________________________________________ 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 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --_000_D617B084E1D24A0EAD7A225BC8AD3400ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <34306FE63CEA7E439DB00D9866BDACE0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
"seamless integration between software and hardware st= ores"
+1

Many times we work with software that assumes different int= erfaces and, perhaps more insidious, assumes that keys are always extracted= from software stores to be used in memory. (For example instead of leverag= ing a crypto engine interface w/in their TLS library they instead pass the raw keys into the library and expe= ct it to be used locally).

- max 

On Nov 8, 2015, at 4:56 AM, Dr. Pala <director@openca.org> wrote:

Hi Russ,

Absolutely. I think that there are a number of high-level c= oncepts that are going to be included in the API definition and the underly= ing implementation can leverage what works today for hardware devices (e.g.= PKCS#11, PKCS#12, MS-CAPI store, etc.).

I totally agree that having seamless integration between so= ftware and hardware stores would be a win-win situation. Standardizing this= interface would also be important.

Cheers,
Max

On Nov 8, 2015, at 12:44 AM, Russ Housley <housley@vigilsec.com> wrote:

Max:

Wouldn't the ideal API be the same for software libraries a= nd hardware devices?  Having the application seamlessly work regardles= s of the manner that the key is stored would be a big win for application d= evelopers.  To this end, some people use PKCS#11 as an interface to software.

Russ


On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote:

Hi Jaroslav,

thanks for the feedback. I do understand your position - however, I do disa= gree with the premises. PKCS#11 is a successful standard when it comes to h= ardware interfaces. However, since its design was targeted to standardizing= interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to ap= plications. Therefore much work is required to fill those gaps (only using = PKCS#11 calls does get you only that far).

This said, I think that learning from the limitations of the solutions we h= ave today is an important step towards specifying the scope of the proposed= work. Maybe we will end up having a similar API or we might provide an hig= her level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try t= o address a real pain by using the only standard API we have today. A comme= ndable effort, but not what I am proposing.

Another important aspect that is usually under-estimated when it comes to c= rypto APIs is usability. I personally think that PKCS#11 is not a great exa= mple from this point of view and, AFAIK, people that have developed against= it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, dev= elopers need to use other interfaces to deal with all extra details when it= comes to, for example, dealing with certificates processing (e.g., chain v= alidation, etc.).

This is my personal opinion, of course, and I do not want to start a discus= sion about if this work is needed or not here (especially because I have al= ready been told that IETF is not interested in this work). I think there is= much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who pra= ctically have felt the pain when developing applications) as possible. If y= ou feel that this is still a pain point today, please join the effort.

Thanks again for the feedback,

Cheers,
Max


On 11/7/15 8:59 AM, Jaroslav Imrich wrote:
Hi Max,

I believe PKCS#11 [0] already provides those benefits, it i= s widely adopted by both commercial and open-source projects and it works n= ot only for hardware but also for pure software crypto implementations - fo= r example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What wo= uld be the benefits of the new API over PKCS#11?

Regards, Jaroslav

[0] https://www.oasis-open.org/committees/pkcs11/
[1] https://www.opendnssec.org/softhsm/
[2] http://thewalter.net/git/cgit.cgi/p11-capi/


On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pal= a <director@openca.org> wrote:
Hi all,

I am not sure this is the right place to write this e-mail, but I hope is. = At the meeting I spoke with several people about an idea I had some time ag= o but never landed at IETF. Since I got positive feedback and suggestion to= post the idea to this list to see if others might be interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to cryptogra= phic libraries. The basic idea is to provide an API that different vendors = can implement on top of their libraries to provide a standard interface for= applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other cry= pto library that provides that interface without having to re-write the cry= pto-related code. This allows for portability (wider adoption of crypto-ena= bled applications), code/modules re-usability, and the possibility for applications to switch between vendo= rs (e.g., switching to a better crypto library or dismissing a library that= has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be att= empted in the past.. ), I was never able to get the green light to proceed = with a proposal for IETF (unfortunately the answer was always "we don'= t do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain th= at needs to be solved. If the IETF will like to pick up the work in the fut= ure, great. If not, we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing specs, = participating in the discussion, provide feedback, or writing code) please = contact me and we'll take it from there. I wrote a couple of pages today (v= ery quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work t= ogether on this. The website is reachable at:

    http://cryptoapi.openca.org/

Last but not least - I am starting also another project that targets the us= e of SYMMETRIC crypto by providing support for encryption at rest. This lib= rary will provide support for storing encrypted data, signed (hmac) data, s= ymmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., deal= ing with symmetric crypto is hard for the average developer since not much = support, outside TLS, is provided). By defining a simple high-level API for= symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environme= nt where asymmetric is not an option (e.g., latency constraints). The idea = is to actually write a standard for symmetric crypto ... "at rest"= ;.

Also for this project, please contact me directly (I still do not have page= s for this project for various reasons - most importantly I still have to s= ee if I get to open source what I did for my employer of if we have to star= t from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions to = are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Res= ource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (= Discovery) System (PKS).


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

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

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

--_000_D617B084E1D24A0EAD7A225BC8AD3400ciscocom_-- From nobody Tue Nov 10 02:22:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72D81B3632 for ; Tue, 10 Nov 2015 02:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCAsEE_eAeS7 for ; Tue, 10 Nov 2015 02:22:25 -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 A3B601B362F for ; Tue, 10 Nov 2015 02:22:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6CE20BE4C; Tue, 10 Nov 2015 10:22:21 +0000 (GMT) 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 z-5VNpPIItPT; Tue, 10 Nov 2015 10:22:21 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0C024BE59; Tue, 10 Nov 2015 10:22:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447150940; bh=/F8B7BeOD8QH9m2qLpUAmEGUVlcGb1k9d8hUtglkkmM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qvRgXIpQo1wwFplTSS+kBoecoVOy/iAQQ8er6mmk0E9AcPTjQ5fXCUXsDun1IX73D 0Lm0v58Z+wkIR+5gsDLYl34bNjzEPngvlaGWZ/pX9QRwa+yJ/rMYYJKioxPNcxWgoH EDJTN5RSbo2kGln79/NH/miVDg/acPLx0e+JZ8RE= To: Benjamin Kaduk References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5641C55B.4040803@cs.tcd.ie> Date: Tue, 10 Nov 2015 10:22:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Simon Josefsson , "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 10:22:28 -0000 (First, I'd really appreciate if folks could give feedback on the general idea here and say if they'd help with some of the work. Without that, we're gonna have a long waiting list for AD-sponsored things for the next quite a few months.) More below on Kerberos... On 07/11/15 06:09, Benjamin Kaduk wrote: > On Fri, 6 Nov 2015, Stephen Farrell wrote: > >> >> On 06/11/15 10:15, Simon Josefsson wrote: >>> >>> To be concrete, I perceive this to be about adding support for >>> Curve25519 key-agreement, Ed25519 digital signatures, and >>> ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also >>> chose Curve448 we ought to include X448/Ed448, although before the CFRG >>> decision I saw close to zero demand from implementers so it will be >>> pushing things down people's throats and will lead to agility complexity >>> concerns but I believe we are okay with that (it would be boring if we >>> had no protocol weaknesses to fix). >>> >>> The protocols that would be relevant are SSH (no active WG), PKIX (no >>> active WG), and DNSSEC (no DNS protocol-related active WG). I believe >>> OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON >>> there is a proposal but no public WG discussion. The Kerberos community >>> have not been active in pursuing modern crypto. > > I'm not sure if you're referring to the people who still haven't switched > off of single-DES (yes, really! Quite a few of them!), or a lack of > interest in post-AES/sha1. > >> Kerberos has the kitten wg as well so is fine. > > On the face of it, maybe. There is a draft proposing AES/SHA2 enctypes, > which got some attention, but the WG is a bit low on energy in general. > Some extra folks helping pull in, e.g., ChaChaa20-Poly1305 would be quite > welcome. The elephant in the room is that if Microsoft doesn't implement > a new enctype for AD, it is unlikely to see widespread adoption. True. One option we could explore is where the putative WG (where there may be energy for a bit) could, with the agreement of the kitten WG (in this case) do some of the work and we could do WGLC in both the putative new WG and in this case kitten. We'd likely want to do something like that with dnsop in any case when it comes to anything touching on the DNS. Cheers, S. > > -Ben > From nobody Tue Nov 10 04:50:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871CC1ACD34 for ; Tue, 10 Nov 2015 04:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 dCB1MPo8bCYJ for ; Tue, 10 Nov 2015 04:50:56 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 ADA8C1A92E7 for ; Tue, 10 Nov 2015 04:50:55 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAACoktF021398 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 Nov 2015 13:50:47 +0100 From: Simon Josefsson To: Benjamin Kaduk References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151110:saag@ietf.org::GGR+xH9czA7cvHOi:2Mex X-Hashcash: 1:22:151110:kaduk@mit.edu::Y2Ie8i3bUO9+Zi13:AZH3 X-Hashcash: 1:22:151110:stephen.farrell@cs.tcd.ie::qzS6DA85AfA5TaUJ:DPyy Date: Tue, 10 Nov 2015 13:50:45 +0100 In-Reply-To: (Benjamin Kaduk's message of "Sat, 7 Nov 2015 01:09:26 -0500 (EST)") Message-ID: <874mguvx0a.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 12:50:57 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk writes: >> > To be concrete, I perceive this to be about adding support for >> > Curve25519 key-agreement, Ed25519 digital signatures, and >> > ChaCha20-Poly1305 integrity-protected encryption. Since the CFRG also >> > chose Curve448 we ought to include X448/Ed448, although before the CFRG >> > decision I saw close to zero demand from implementers so it will be >> > pushing things down people's throats and will lead to agility complexity >> > concerns but I believe we are okay with that (it would be boring if we >> > had no protocol weaknesses to fix). >> > >> > The protocols that would be relevant are SSH (no active WG), PKIX (no >> > active WG), and DNSSEC (no DNS protocol-related active WG). I believe >> > OpenPGP, TLS, IPSEC have active WGs that is working on this. For JSON >> > there is a proposal but no public WG discussion. The Kerberos community >> > have not been active in pursuing modern crypto. > > I'm not sure if you're referring to the people who still haven't switched > off of single-DES (yes, really! Quite a few of them!), or a lack of > interest in post-AES/sha1. With "modern crypto" I refer to crypto designed for the classical requirements that have good implementation characteristics such as high performance and amenable to some flavor of side-channel protection. AES has okay performance (compared with for example 3DES), but not particulary nice side-channel properties, and is often used in insecure modes (non-AEAD). So in the "modern crypto" category, I would not count AESand would include ChaCha20-Poly1305, Curve25519, and Ed25519. If anyone has a better term than "modern crypto" that would be useful. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWQeglAAoJEIYLf7sy+BGdyI8IAIV7YXS0EAMVMrri3BayjY5Q WmRybXK2ww1+m02pHX6DD+WD/y3dEL/atWn1rqYJ5OMsi67iVfIeGhK8TeqZGuFm guYlexOKN6LJNIvy7JhCnlFpIRduD8sjDO0kkZ/b1yqUhjgBEsEtdyGGun0gGpLY HLon/O2TeDw4PrfYZGi4hr42bXdGpup1ff04gO3/zg0AfKtMCjRiv+rheoBILtdy 8Kxo80C0O7XJAx7s4eaPbj+uV6ZMbBHLErZiryw48/tIAGhwgi4Wm7B/XITl5Q4q GGTFT7SoQJtsuMke4HkXoMVyAo+d2pJiAh5DPpZdD5ibzdqoExSAVn9JnNnR/+c= =fc/X -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 10 04:54:28 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488151ACD81 for ; Tue, 10 Nov 2015 04:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 yNggA7P9fYZy for ; Tue, 10 Nov 2015 04:54:26 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 5007F1ACD7E for ; Tue, 10 Nov 2015 04:54:26 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAACsHo2021415 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 Nov 2015 13:54:18 +0100 From: Simon Josefsson To: Stephen Farrell References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> <5641C55B.4040803@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151110:stephen.farrell@cs.tcd.ie::V8zJ06jdy1ZtQOlD:K/9 X-Hashcash: 1:22:151110:kaduk@mit.edu::mOOSQAMeYQvHxgGL:31k3 X-Hashcash: 1:22:151110:saag@ietf.org::GXJINDpM9ml5zIsr:4UBK Date: Tue, 10 Nov 2015 13:54:16 +0100 In-Reply-To: <5641C55B.4040803@cs.tcd.ie> (Stephen Farrell's message of "Tue, 10 Nov 2015 10:22:19 +0000") Message-ID: <87ziymui9z.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 12:54:27 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > (First, I'd really appreciate if folks could give feedback on the > general idea here and say if they'd help with some of the work. > Without that, we're gonna have a long waiting list for AD-sponsored > things for the next quite a few months.) If it would actually speed up the publication process (something I'm not convinced of, but my viewpoint may be limited) I'm happy to help with draft/charter reviews, draft editing, and proto-writeups. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWQej4AAoJEIYLf7sy+BGdB1IIAKBGd5KEFvUcB+0m40togt0f p0U8An46FBbKCEqpnhabVkbk19q77F9StYzLBtQqjimSJ5dL1XNSLbiFbQxivWd5 GewX5J0ZZizXKz0/iIZUAldDpzIJgijs+HDXEkefXepFDufBfyvMfYrGSoqR73YJ +UtaHZVm1wu4NFg5rjhP7N5o+MQG7WptAItAn8k05i/GDT2JnCu0uaXfFFzJZXj1 kRWBzcNX2N3ZSC9hF+Q62mx4pJXU1CfC7D9A4Yv6dr7nZtly4IdayMK0q7R5AERf QouWqJc2vCA88KlGbB53G97lYuFus3yKpznHtW0s4+Xb3cdGsJg/Ju+ai4S1mgc= =H5to -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 10 05:55:04 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175FB1AD35C for ; Tue, 10 Nov 2015 05:54: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXNl30s2VLyr for ; Tue, 10 Nov 2015 05:54:56 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 272CA1AD35F for ; Tue, 10 Nov 2015 05:54:51 -0800 (PST) Received: by wmdw130 with SMTP id w130so71919594wmd.0 for ; Tue, 10 Nov 2015 05:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cr5k+1AVsGXxRIy8olnPx2OPgnfHqs/TBOPK+KHOFEA=; b=ba7ZwV7rFuoN4Uci7Rz90uw5zWUSVLG2iImno5la5b83hh2c7t/o5zx4iADzPUGSN7 8ULLw7aLu+gO4o3MNHXh1WQS7ZXMv7P50XGIqERx9E+UQWZCD2KNUAUQZhelH9XEn6fB Z3DkXS6Q+JsBEsvC40o1palNe6DjGoL2AHSHV1sMurBm2z54x2eCy6TFIad8Zg9wOFX5 M4kc27dmi7B8bpyXuk+IuOECAQfTEOTAqnT4VqCA4LxNec6o47q9kSNmPjD0LJj/lKOi y/ITGmvaGQG6Dqz4/8n21EG2kNw/MpjLT/4v/MVgrxTmeEKDD7i36VBYImjje/mO4hjp wE0w== X-Received: by 10.28.92.209 with SMTP id q200mr35533152wmb.52.1447163689706; Tue, 10 Nov 2015 05:54:49 -0800 (PST) Received: from [172.24.251.94] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id t20sm19979988wme.0.2015.11.10.05.54.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Nov 2015 05:54:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <87ziymui9z.fsf@latte.josefsson.org> Date: Tue, 10 Nov 2015 15:54:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36FD5132-B649-47C2-848B-F3F0B85A72E7@gmail.com> References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> <5641C55B.4040803@cs.tcd.ie> <87ziymui9z.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 13:54:58 -0000 > On 10 Nov 2015, at 2:54 PM, Simon Josefsson = wrote: >=20 > Stephen Farrell writes: >=20 >> (First, I'd really appreciate if folks could give feedback on the >> general idea here and say if they'd help with some of the work. >> Without that, we're gonna have a long waiting list for AD-sponsored >> things for the next quite a few months.) >=20 > If it would actually speed up the publication process (something I'm = not > convinced of, but my viewpoint may be limited) I'm happy to help with > draft/charter reviews, draft editing, and proto-writeups. Me too.=20 I think recent evidence has shown that having an algorithm document from = CFRG makes the protocol WG process much easier. Having RFC 7539 meant = that the drafts for IPsecME and TLS were accepted quickly, were kept = short and proceeded through last calls (so far only IPsec) with no = hand-wringing over =E2=80=9Chow do we know if this is a good idea or = secure=E2=80=9D. I think the Curves documents are doing the same. But if we start writing kitten documents, I=E2=80=99m afraid we=E2=80=99re= going to run into people who tell us, =E2=80=9Cno, no, no, you don=E2=80=99= t understand Kerberos. This is all wrong.=E2=80=9D So I=E2=80=99m not = sure this will solve more problems that it creates. Yoav From nobody Tue Nov 10 05:55:22 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AA41AD34F for ; Tue, 10 Nov 2015 05:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W7pgO-qR8qc for ; Tue, 10 Nov 2015 05:55:11 -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 641B81AD49B for ; Tue, 10 Nov 2015 05:55:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39E3EBE5C; Tue, 10 Nov 2015 13:55:00 +0000 (GMT) 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 RtySxmKv54Am; Tue, 10 Nov 2015 13:55:00 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A98DBE5D; Tue, 10 Nov 2015 13:54:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447163700; bh=+YZ8SNnccYDik3Xu92a3Vmq5Tu7MWddycqAhoMsxg54=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=iUTUypqhIUbd0txLZfQ4aTFJ0PdPRsy+jQKmJUp8nS3L22n6u/64wG+jOljTXTMDg ZTK2YtAYbtSXQrNl592LDRtj5T4kPm0FZFblUxQ8DGhAObLG3zMpdeX487TU5MnUny ix5zthmPnjzt7rWYWm1H9lo5ef2n7DpjHYX65q5I= To: Simon Josefsson References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> <5641C55B.4040803@cs.tcd.ie> <87ziymui9z.fsf@latte.josefsson.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5641F732.8030600@cs.tcd.ie> Date: Tue, 10 Nov 2015 13:54:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <87ziymui9z.fsf@latte.josefsson.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 13:55:14 -0000 On 10/11/15 12:54, Simon Josefsson wrote: > Stephen Farrell writes: > >> (First, I'd really appreciate if folks could give feedback on the >> general idea here and say if they'd help with some of the work. >> Without that, we're gonna have a long waiting list for AD-sponsored >> things for the next quite a few months.) > > If it would actually speed up the publication process (something I'm not > convinced of, but my viewpoint may be limited) I'm happy to help with > draft/charter reviews, draft editing, and proto-writeups. Thanks Simon. With 6-8 drafts (if we have that many) a WG would speed up the process and would also remove potential doubts about IETF consensus I think. Cheers, S. > > /Simon > From nobody Tue Nov 10 06:00:12 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D4B1B29F5 for ; Tue, 10 Nov 2015 06:00:10 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXuZdx2ljYgC for ; Tue, 10 Nov 2015 06:00:05 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860121B29F4 for ; Tue, 10 Nov 2015 06:00:05 -0800 (PST) Received: by wmdw130 with SMTP id w130so72127923wmd.0 for ; Tue, 10 Nov 2015 06:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w9Ww234psso6X5yFbgZpDXux2N2fGnJu8A5fUSv5Wxs=; b=wMnZwiijkZXW0Ek1JViCV2mluDAzA0TKUDQPoWew6Cp44eZOUzOp9ueAWsPT7uiu+b uyVEs3PfRGycljnuOXUb84IsXXJhTiUf8DZBLFI6OeMk1qF6YkujqFsOPGmeysf7eyJZ bLErEyQvVcWf5DqE3/Lb3pwSvjpfOzHi5+GozFyqSl95F6i1a3cgMu7uwrH4d7ydblCd 9VsBALvOF8I1cx5YzPDnR/Q8sFJR94rb29epOeOIDfGkqd4lPMhuNy0ptjb+LfpuLK63 oW/nxqGwhMsVn6L7FsoQHMcqsyQ/ZbKu5P2BbXh98lImvGY8vgVSKT2OBjF+a8LkonJ/ Sqnw== X-Received: by 10.28.100.84 with SMTP id y81mr5384548wmb.48.1447164003793; Tue, 10 Nov 2015 06:00:03 -0800 (PST) Received: from [172.24.251.94] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id jh4sm3664072wjb.33.2015.11.10.06.00.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Nov 2015 06:00:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <5641F732.8030600@cs.tcd.ie> Date: Tue, 10 Nov 2015 16:00:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> <5641C55B.4040803@cs.tcd.ie> <87ziymui9z.fsf@latte.josefsson.org> <5641F732.8030600@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Simon Josefsson , Security Area Advisory Group Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:00:10 -0000 > On 10 Nov 2015, at 3:54 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 10/11/15 12:54, Simon Josefsson wrote: >> Stephen Farrell writes: >>=20 >>> (First, I'd really appreciate if folks could give feedback on the >>> general idea here and say if they'd help with some of the work. >>> Without that, we're gonna have a long waiting list for AD-sponsored >>> things for the next quite a few months.) >>=20 >> If it would actually speed up the publication process (something I'm = not >> convinced of, but my viewpoint may be limited) I'm happy to help with >> draft/charter reviews, draft editing, and proto-writeups. >=20 > Thanks Simon. With 6-8 drafts (if we have that many) a WG would > speed up the process and would also remove potential doubts about > IETF consensus I think. >=20 > Cheers, > S. Are there any candidate drafts now? Yoav From nobody Tue Nov 10 06:34:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F215A1B2B95 for ; Tue, 10 Nov 2015 06:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 9S1P5r2SrKsW for ; Tue, 10 Nov 2015 06:34:08 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 BE8B61B2B96 for ; Tue, 10 Nov 2015 06:34:06 -0800 (PST) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::a86]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAAEXtj2031417 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 10 Nov 2015 15:33:56 +0100 Date: Tue, 10 Nov 2015 15:33:49 +0100 From: Simon Josefsson To: Yoav Nir Message-ID: <20151110153349.60826d1c@latte.josefsson.org> In-Reply-To: References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> <5641C55B.4040803@cs.tcd.ie> <87ziymui9z.fsf@latte.josefsson.org> <5641F732.8030600@cs.tcd.ie> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/TtXX1Smqng/bQswR1pC3EZv"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 14:34:09 -0000 --Sig_/TtXX1Smqng/bQswR1pC3EZv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > Are there any candidate drafts now? The IPSECME WG have accepted a document on key agreement. The TLS WG (which spawned the CFRG discussion) accepted key agreement, and the latest WG document RFC 4492bis discuss signatures although I don't recall any consensus call about adding that. The OpenPGP WG have EdDSA signatures. The further non-WG documents I can recall now include: SSH --- ed25519 sign https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 curve25519+curve448 kex: https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 missing: ed448 PKIX ---- Curve25519+Curve448 namedCurve: https://tools.ietf.org/html/draft-josefsson-pkix-newcurves EdDSA Ed25519(ph) and Ed448(ph) https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 DNS --- Ed25519: https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 Ed448: https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 JSON ---- There is an unpublished proposal floating around. /Simon --Sig_/TtXX1Smqng/bQswR1pC3EZv Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWQgBNAAoJEIYLf7sy+BGdnqYH/0UeL5fMkjz105bkMEgLp+ar 5ei6NMepf9oXWHyQap90vtwTmJqvet67+d+gRbSCOLg57muKP82yt04iSceqv2+e wQP8OyWeRZecJoO83gdRvGICj44uu3vfbM321VSs1XzBAVr+fujtzb57ccDlCeIZ oDJ5p7aPpy7+2pxB/b9z9J0Rp97bcmbJ0mZgt3qftbJ3bLwVjJExa8j8ZP3YS7YX cPVdPoLFyhzyssjCzty4lzdhccX4K8ZegDT/7JA2v2BUc8dJLz/h21Ciu31qBZr1 KusK+XbOxG4fwM6FnSqEEiJOkHNp8PygqT+i26Mh7vIvyuB1qWx/XMmlWXxun5w= =COuz -----END PGP SIGNATURE----- --Sig_/TtXX1Smqng/bQswR1pC3EZv-- From nobody Wed Nov 11 01:55:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5C11B495C for ; Wed, 11 Nov 2015 01:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.966 X-Spam-Level: X-Spam-Status: No, score=0.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=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 1ALMpVWOe_pa for ; Wed, 11 Nov 2015 01:55:34 -0800 (PST) Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C1B1B4956 for ; Wed, 11 Nov 2015 01:55:33 -0800 (PST) Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id 31A474205C; Wed, 11 Nov 2015 10:55:16 +0100 (CET) Received: from [22.187.216.95] (unknown [172.56.23.51]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id 72A7918A08D4; Sun, 8 Nov 2015 06:48:59 -0500 (EST) Content-Type: multipart/signed; boundary=Apple-Mail-1E6589FD-9AF1-4160-BC52-2A5FBF0419ED; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: "Dr. Pala" X-Mailer: iPhone Mail (13B143) In-Reply-To: <090207A0-65F1-4605-B19B-AF0DDFBF61E1@vigilsec.com> Date: Sun, 8 Nov 2015 06:47:45 -0500 Content-Transfer-Encoding: 7bit Message-Id: <1B5B40A4-57F8-4984-8744-18391498B937@openca.org> References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> <090207A0-65F1-4605-B19B-AF0DDFBF61E1@vigilsec.com> To: Russ Housley Archived-At: Cc: IETF SAAG Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 09:55:38 -0000 --Apple-Mail-1E6589FD-9AF1-4160-BC52-2A5FBF0419ED Content-Type: multipart/alternative; boundary=Apple-Mail-90FA9A4F-963F-4B4E-888D-2A98A5B43DB9 Content-Transfer-Encoding: 7bit --Apple-Mail-90FA9A4F-963F-4B4E-888D-2A98A5B43DB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Russ, Absolutely. I think that there are a number of high-level concepts that are g= oing to be included in the API definition and the underlying implementation c= an leverage what works today for hardware devices (e.g. PKCS#11, PKCS#12, MS= -CAPI store, etc.). I totally agree that having seamless integration between software and hardwa= re stores would be a win-win situation. Standardizing this interface would a= lso be important. Cheers, Max > On Nov 8, 2015, at 12:44 AM, Russ Housley wrote: >=20 > Max: >=20 > Wouldn't the ideal API be the same for software libraries and hardware dev= ices? Having the application seamlessly work regardless of the manner that t= he key is stored would be a big win for application developers. To this end= , some people use PKCS#11 as an interface to software. >=20 > Russ >=20 >=20 >> On Nov 8, 2015, at 12:38 AM, Massimiliano Pala wrote: >>=20 >> Hi Jaroslav, >>=20 >> thanks for the feedback. I do understand your position - however, I do di= sagree with the premises. PKCS#11 is a successful standard when it comes to h= ardware interfaces. However, since its design was targeted to standardizing i= nterfaces for hardware devices, it does not always provide the easiest / bes= t approach when it comes to applications. Therefore much work is required to= fill those gaps (only using PKCS#11 calls does get you only that far). >>=20 >> This said, I think that learning from the limitations of the solutions we= have today is an important step towards specifying the scope of the propose= d work. Maybe we will end up having a similar API or we might provide an hig= her level one or, again, a simplified version of it. In my opinion, all the s= olutions you are listing here try to address a real pain by using the only s= tandard API we have today. A commendable effort, but not what I am proposing= . >>=20 >> Another important aspect that is usually under-estimated when it comes to= crypto APIs is usability. I personally think that PKCS#11 is not a great ex= ample from this point of view and, AFAIK, people that have developed against= it have often resorted to develop their own abstraction layer on top of it.= Moreover, most of the times, developers need to use other interfaces to dea= l with all extra details when it comes to, for example, dealing with certifi= cates processing (e.g., chain validation, etc.). >>=20 >> This is my personal opinion, of course, and I do not want to start a disc= ussion about if this work is needed or not here (especially because I have a= lready been told that IETF is not interested in this work). I think there is= much to be done and I am happy to discuss all these aspects and collaborate= with as many experts (who practically have felt the pain when developing ap= plications) as possible. If you feel that this is still a pain point today, p= lease join the effort. >>=20 >> Thanks again for the feedback, >>=20 >> Cheers, >> Max >>=20 >>=20 >>> On 11/7/15 8:59 AM, Jaroslav Imrich wrote: >>> Hi Max, >>>=20 >>> I believe PKCS#11 [0] already provides those benefits, it is widely adop= ted by both commercial and open-source projects and it works not only for ha= rdware but also for pure software crypto implementations - for example SoftH= SM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top o= f MS CAPI. What would be the benefits of the new API over PKCS#11? >>>=20 >>> Regards, Jaroslav >>>=20 >>> [0] https://www.oasis-open.org/committees/pkcs11/ >>> [1] https://www.opendnssec.org/softhsm/ >>> [2] http://thewalter.net/git/cgit.cgi/p11-capi/ >>>=20 >>>=20 >>>> On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala = wrote: >>>> Hi all, >>>>=20 >>>> I am not sure this is the right place to write this e-mail, but I hope i= s. At the meeting I spoke with several people about an idea I had some time a= go but never landed at IETF. Since I got positive feedback and suggestion to= post the idea to this list to see if others might be interested, here's the= summary e-mail. >>>>=20 >>>> The idea is very simple: provide specifications for inter= faces to cryptographic libraries. The basic idea is to provide an API that d= ifferent vendors can implement on top of their libraries to provide a standa= rd interface for applications. If successful, an application could make use o= f OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that= interface without having to re-write the crypto-related code. This allows f= or portability (wider adoption of crypto-enabled applications), code/modules= re-usability, and the possibility for applications to switch between vendor= s (e.g., switching to a better crypto library or dismissing a library that h= as shown vulnerabilities). >>>>=20 >>>> Although I received positive feedback about the idea (I know, it has be= attempted in the past.. ), I was never able to get the green light to proce= ed with a proposal for IETF (unfortunately the answer was always "we don't d= o APIs" ... which, actually, it is not true), so I decided to move forward a= nyway, since it is a real pain that needs to be solved. If the IETF will lik= e to pick up the work in the future, great. If not, we'll solve the problem a= nyway :D >>>>=20 >>>> If you are interested in participating in the effort (e.g., writing spe= cs, participating in the discussion, provide feedback, or writing code) plea= se contact me and we'll take it from there. I wrote a couple of pages today (= very quick and dirty work for now.. so.. don't judge!), but I hope we'll be a= ble to gather momentum and work together on this. The website is reachable a= t: >>>>=20 >>>> http://cryptoapi.openca.org/ >>>>=20 >>>> Last but not least - I am starting also another project that targets th= e use of SYMMETRIC crypto by providing support for encryption at rest. This l= ibrary will provide support for storing encrypted data, signed (hmac) data, s= ymmetric keys, and symmetric keys bundles (stack of keys) in s= uch a way that it is simple to use (e.g., dealing with symmetric crypto is h= ard for the average developer since not much support, outside TLS, is provid= ed). By defining a simple high-level API for symmetric crypto we want to fil= l the gap and, hopefully, increase the use of crypto also in those environme= nt where asymmetric is not an option (e.g., latency constraints). The idea i= s to actually write a standard for symmetric crypto ... "at rest". >>>>=20 >>>> Also for this project, please contact me directly (I still do not have p= ages for this project for various reasons - most importantly I still have to= see if I get to open source what I did for my employer of if we have to sta= rt from scratch) at this e-mail address. >>>>=20 >>>> Happy Security Everybody! >>>>=20 >>>> Cheers, >>>> Max >>>>=20 >>>> P.S.: Other items on the back burner that I would welcome contributions= to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI R= esource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (= Discovery) System (PKS). >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --Apple-Mail-90FA9A4F-963F-4B4E-888D-2A98A5B43DB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Russ,

Absolutely. I think that the= re are a number of high-level concepts that are going to be included in the A= PI definition and the underlying implementation can leverage what works toda= y for hardware devices (e.g. PKCS#11, PKCS#12, MS-CAPI store, etc.).

I tota= lly agree that having seamless integration between software and hardware sto= res would be a win-win situation. Standardizing this interface would also be= important.

Cheers,<= div>Max

On Nov 8, 2015, at 12:44 AM, Russ Housley &= lt;housley@vigilsec.com> wrot= e:

Max:

Would= n't the ideal API be the same for software libraries and hardware devices? &= nbsp;Having the application seamlessly work regardless of the manner that th= e key is stored would be a big win for application developers.  To this= end, some people use PKCS#11 as an interface to software.

Russ


On Nov 8, 2015, at 12:38= AM, Massimiliano Pala wrote:

<= blockquote type=3D"cite"> =20 =20
Hi Jaroslav,

thanks for the feedback. I do understand your position - however, I do disagree with the premises. PKCS#11 is a successful standard when it comes to hardware interfaces. However, since its design was targeted to standardizing interfaces for hardware devices, it does not always provide the easiest / best approach when it comes to applications. Therefore much work is required to fill those gaps (only using PKCS#11 calls does get you only that far).

This said, I think that learning from the limitations of the solutions we have today is an important step towards specifying the scope of the proposed work. Maybe we will end up having a similar API or we might provide an higher level one or, again, a simplified version of it. In my opinion, all the solutions you are listing here try to address a real pain by using the only standard API we have today. A commendable effort, but not what I am proposing.

Another important aspect that is usually under-estimated when it comes to crypto APIs is usability. I personally think that PKCS#11 is not a great example from this point of view and, AFAIK, people that have developed against it have often resorted to develop their own abstraction layer on top of it. Moreover, most of the times, developers need to use other interfaces to deal with all extra details when it comes to, for example, dealing with certificates processing (e.g., chain validation, etc.).

This is my personal opinion, of course, and I do not want to start a discussion about if this work is needed or not here (especially because I have already been told that IETF is not interested in this work). I think there is much to be done and I am happy to discuss all these aspects and collaborate with as many experts (who practically have felt the pain when developing applications) as possible. If you feel that this is still a pain point today, please join the effort.

Thanks again for the feedback,

Cheers,
Max


On 11/7/15 8:59 AM, Jaroslav Imrich wrote:
Hi Max,

I believe PKCS#11 [0] already provides those benefits, it is widely adopted by both commercial and open-source projects and it works not only for hardware but also for pure software crypto implementations - for example SoftHSM [1] works nicely on top of OpenSSL and Botan, p11-capi [2] works on top of MS CAPI. What would be the benefits of the new API over PKCS#11?

Regards, Jaroslav


On Sat, Nov 7, 2015 at 2:30 PM, Massimiliano Pala <director@openca.= org> wrote:
Hi all,

I am not sure this is the right place to write this e-mail, but I hope is. At the meeting I spoke with several people about an idea I had some time ago but never landed at IETF. Since I got positive feedback and suggestion to post the idea to this list to see if others might be interested, here's the summary e-mail.

The idea is very simple: provide specifications for interfaces to cryptographic libraries. The basic idea is to provide an API that different vendors can implement on top of their libraries to provide a standard interface for applications. If successful, an application could make use of OpenSSL, MS-CAPI, Cryptlib, or any other crypto library that provides that interface without having to re-write the crypto-related code. This allows for portability (wider adoption of crypto-enabled applications), code/modules re-usability, and the possibility for applications to switch between vendors (e.g., switching to a better crypto library or dismissing a library that has shown vulnerabilities).

Although I received positive feedback about the idea (I know, it has be attempted in the past.. ), I was never able to get the green light to proceed with a proposal for IETF (unfortunately the answer was always "we don't do APIs" ... which, actually, it is not true), so I decided to move forward anyway, since it is a real pain that needs to be solved. If the IETF will like to pick up the work in the future, great. If not, we'll solve the problem anyway :D

If you are interested in participating in the effort (e.g., writing specs, participating in the discussion, provide feedback, or writing code) please contact me and we'll take it from there. I wrote a couple of pages today (very quick and dirty work for now.. so.. don't judge!), but I hope we'll be able to gather momentum and work together on this. The website is reachable at:

    http://cryptoapi.open= ca.org/

Last but not least - I am starting also another project that targets the use of SYMMETRIC crypto by providing support for encryption at rest. This library will provide support for storing encrypted data, signed (hmac) data, symmetric keys, and symmetric keys bundles (stack of keys) in such a way that it is simple to use (e.g., dealing with symmetric crypto is hard for the average developer since not much support, outside TLS, is provided). By defining a simple high-level API for symmetric crypto we want to fill the gap and, hopefully, increase the use of crypto also in those environment where asymmetric is not an option (e.g., latency constraints). The idea is to actually write a standard for symmetric crypto ... "at rest".

Also for this project, please contact me directly (I still do not have pages for this project for various reasons - most importantly I still have to see if I get to open source what I did for my employer of if we have to start from scratch) at this e-mail address.

Happy Security Everybody!

Cheers,
Max

P.S.: Other items on the back burner that I would welcome contributions to are OCSP over DNS (ODIN), Lightweight Revocation Tokens (LIRT), the PKI Resource Query Protocol (PRQP), Simplified CMC over HTTP, and the Public Key (Discovery) System (PKS).


_______________________________________________
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<= br>

= --Apple-Mail-90FA9A4F-963F-4B4E-888D-2A98A5B43DB9-- --Apple-Mail-1E6589FD-9AF1-4160-BC52-2A5FBF0419ED Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFQjCCBT4w ggQmoAMCAQICEQDrBY3cY3XzPSAQqnn+iw5pMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTUxMTA4MDAwMDAwWhcNMTYxMTA3MjM1 OTU5WjAkMSIwIAYJKoZIhvcNAQkBFhNkaXJlY3RvckBvcGVuY2Eub3JnMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArfcvp27noyzBN+WYa2H6Vh/+Ok8G8QSvjWhszqn4rqKMizRbKWxL grE92Em9bV6XCxeGcVYX30PZzF+VHwwjo9yxoVkOOjYxTIpjA17TJBH2V1veMmtJhCg6L/KpGXSB 8VXxK0pQcYK8shpr7/pR8NSfQQhS9639Ib/oBF7JzZjmgFPfLgavyzF7zQq3GBsSQpicITYwtpnI RG78vUK/KE9Cv0UgKMULDgOIvQRbx/In1jvPD5Aj1gBm6nFAG0iPFwfW2zLQVePSqwXzxCBmzKCu ymxDv39tSRjJkTPWfCZAM/NzLhI411sytcKEXMi/Ud0/iF+7d3KeSwKQUPoBdQIDAQABo4IB8TCC Ae0wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFJoTLU8DzRcG2QKK b0acLDP8n3aIMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwXQYDVR0f BFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xpZW50QXV0 aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAwWAYIKwYB BQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9k b2NhLmNvbTAeBgNVHREEFzAVgRNkaXJlY3RvckBvcGVuY2Eub3JnMA0GCSqGSIb3DQEBCwUAA4IB AQBzIbk8Y+p0XPyIv1/q+Pt+BKpK7wY2JwHM9XCsoMbZnz5IfdQNapELTH5NRSfsZ+DCjvNrkatC 5az3Gn3FLRdPyRlKGWVirgrwnjHTOVVfLyqmNeV2Z8FbtAJFRbY/XJA+GJH680kL1PcL99SvJIVr ZK8V0a0fr6tLjymnLPXpjYaYkACIOuUdXrlaHRydBxwsQhTIwxkHsYNpx64o3nF64Wx5LMyqkQmY FDMV91yO3QqN6tzgTgQiw8+RQm5mXbDvoeFjZoq18pM20AI+aX34ZottOfNPRKuEE/AP7h08x7k1 +AUYkcRjYXFj/SJVc2eeGI0wXHbVwB4tFkZMZ7OzMYIDxjCCA8ICAQEwgbEwgZsxCzAJBgNVBAYT AkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOsFjdxjdfM9IBCqef6LDmkwCQYFKw4D AhoFAKCCAekwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUxMTA4 MTE0NzQ1WjAjBgkqhkiG9w0BCQQxFgQUr252KKtoWtf5m6ilUuTzVsbORPQwgcIGCSsGAQQBgjcQ BDGBtDCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9E TyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA6wWN 3GN18z0gEKp5/osOaTCBxAYLKoZIhvcNAQkQAgsxgbSggbEwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOsFjdxjdfM9IBCqef6LDmkwDQYJKoZIhvcNAQEBBQAE ggEAOXhisKYFIAAfUUdDUwsyZrxZR4GVTxjZx1oPgJCUebC5XELFB/53idgcMPZnIWwu0ZIwJlRl xb4ubQPu32sma5aqSwj2+EWU/TU4ATZfDnwpXTRwi3m0P2zWo51J9jAnz3jpSX4ep/ab4661Y/wz w8btB7KzlgWrQWZ3RhGDTr3aEFfnuHXzmG2q0SoduQp0bDvejfx0zdRDHgjuobCzE+ZBEP6R16lE Xx35Cg78KNvqJeMDJk01GtmEslUZMrRMlsH9TbmArFisT26dQtsgPANpatDHcwg/QaG4iuhI9Nom SMnsBO8HLGoLmUZpFc5jaNoopgQalLOQcj1Ap8LrrgAAAAAAAA== --Apple-Mail-1E6589FD-9AF1-4160-BC52-2A5FBF0419ED-- From nobody Wed Nov 11 08:08:08 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752CC1B2B1E for ; Wed, 11 Nov 2015 08:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.954 X-Spam-Level: X-Spam-Status: No, score=0.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 Y3VR_5Zp-XjS for ; Wed, 11 Nov 2015 08:08:05 -0800 (PST) Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1D01B2B1D for ; Wed, 11 Nov 2015 08:08:04 -0800 (PST) Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id B612141DC2 for ; Wed, 11 Nov 2015 17:07:47 +0100 (CET) Received: from iMassi.local (unknown [65.115.226.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id 01F4C1892817 for ; Wed, 11 Nov 2015 11:07:41 -0500 (EST) To: saag@ietf.org References: <563DFCFB.8090405@openca.org> <563F485F.8@iang.org> From: Massimiliano Pala Organization: OpenCA Labs Message-ID: <564367CD.3050202@openca.org> Date: Wed, 11 Nov 2015 11:07:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563F485F.8@iang.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 16:08:07 -0000 Hi Iang, I do understand the fact that this is a big effort, and it might be difficult to provide the right level of abstraction. That is why I am seeking people that has had these issues to participate in the project so we can get a usable API that can be supported by all the vendors. The WG (outside the IETF - the recent message from Farrell explains his position on this topic) I am proposing is about: (a) discussing and defining what to address with this API and what level of abstraction, and (b) understanding how this API will interact with the lower level (e.g. the crypto API) in order to be sure that we are not limiting / excluding any vendors, and (c) providing a common discussion environment for API implementers that might drive changes related to the proposed standard to make it (besides developers friendly) vendors friendly. This said, one of the benefits that can come out of this project for vendors (here addressing a bit Farrell's concern) is that by having this reference API, they might help their design. Also, third-parties can develop the interfaces (e.g., OpenCryptoAPI for MS-CAPI, OpenSSL, or Crypto++), thus providing new opportunities in the crypto space (e.g., both commercial and non-commercial). We will work on this (unfortunately outside IETF for now), and we will try to push the results in many standardization bodies (therefore we how to see the specs implemented in many different environments and for different programming languages). If we do a good job, we might also prevent developers (not crypto-experts) to shoot themselves in the foot :D Thanks for the feedback, Cheers, Max On 11/8/15 8:04 AM, ianG wrote: > On 7/11/2015 13:30 pm, Massimiliano Pala wrote: > >> The idea is very simple: provide specifications for interfaces to >> cryptographic libraries. > > In my experience, this is not a good idea. I do agree that people are > going to do it anyway, because the world of developers is built to > create new and better and more standard APIs, but doing it is just > their learning experience. > > Some reasons... because it's Sunday. > > * In theory there is a notion that forcing one good API on everyone > will improve their code security, but in practice there are so many > ways to shoot yourself in the foot that it might not be able to show a > benefit. > > * The API that is wanted tends to be different with every project. > Every project has a different threat model. There is a myth that the > SSL threat model is kind of useful for other projects, and this has > driven a lot of API design, for example the certificates, but the SSL > threat model isn't even coherent within its own domain. Borrowing it > without thought is just security negligence because most projects are > based on datagrams [0], so even their architecture mitigates against > the open continuous reliable pipe design that SSL blithely inherits > from TCP without question. > > * In practice, what people need is a much higher level API than is > normally provided. For an example of this have a look at DJB's > cryptobox. After much hacking I ended up with the same approach in my > code, there is no middle level API, there is instead many similar > silos in a pattern I call BusyBee [1]. > > * In the alternate, there is an extreme failing from the API approach > which is epitomised by the Java JCE. In this monstrosity, not only > can you be unsure which library you're getting, you can't really be > sure you're even "allowed" to use crypto. So we get this continual > user configuration nightmare. From a security pov, JCE is unauditable > so we're in this weird position of using 256bit strength crypto but we > can only use it in middling applications where we don't mind if it all > gets perverted by the oracle-in-the-muddle attack. > > * And that's without looking at the overall failure of the API to keep > up with modern times, and the failure to deprecate and improve > ciphersuites, and the complexity of figuring out what is going on > through layers like mobile phones: application -> manufacturer -> > Android -> google -> oracle -> Java JCE. Yes, there have been several > exploits / failures that can be purely attributed to supply chain > madness. And money was lost, in the Bitcoin world, where they > blithely just used this crypto stuff they were given and it turned out > to be flawed. > > * One good argument for an API is that the library meets it and > therefore that code doesn't have to be written by the programmer. This > is good. But this says nothing about the level that is appropriate. > > > > iang > > [0] I'm precisely saying datagrams here, not UDP. > [1] because it does everything and buzzes a lot getting it done. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Nov 11 08:21:01 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB891B2B75 for ; Wed, 11 Nov 2015 08:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.954 X-Spam-Level: X-Spam-Status: No, score=0.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=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 2T_q4nk7FMxw for ; Wed, 11 Nov 2015 08:20:57 -0800 (PST) Received: from server.hackmasters.net (unknown [217.133.36.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FDF1B2B55 for ; Wed, 11 Nov 2015 08:20:56 -0800 (PST) Received: from mail.openca.org (unknown [192.168.101.1]) by server.hackmasters.net (Postfix) with ESMTP id D425A41DC2; Wed, 11 Nov 2015 17:20:09 +0100 (CET) Received: from iMassi.local (unknown [65.115.226.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.openca.org (Postfix) with ESMTPSA id 2A3C81892817; Wed, 11 Nov 2015 11:14:58 -0500 (EST) To: Stephen Farrell References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> <563F6200.5040107@cs.tcd.ie> From: Massimiliano Pala Organization: OpenCA Labs Message-ID: <56436981.6070303@openca.org> Date: Wed, 11 Nov 2015 11:14:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563F6200.5040107@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 16:20:58 -0000 Hi Sephen, thanks for letting me know your point of view. I would really like to bring this work to the IETF, as I think it is a practical engineering issue that could be addressed by having a standard and related implementations. I already received some support from several Crypto API vendors and I think we might see (finally) this happening in the real world. As I wrote in my other reply to iang, part of the work is to be sure we do not exclude vendors as our purpose is to be available everywhere. I am thinking about the success of the LDAP API that is implemented on every single system I have worked on and by all the vendors I am aware of. Our scope might be a bit more broad, and we might end up splitting the effort in different documents (e.g., SSL/TLS, PKIX, SYMCRYPTO, etc.) - I cannot predict it now. I am very fond of the IETF and I have been participating to the WGs for more than 15 yrs now, but if this is your position we do not have any alternative but to work outside the organization for now. I still hope that this will change at some point. Thanks Again, Cheers, Max On 11/8/15 9:53 AM, Stephen Farrell wrote: > Hi Max, > > I've no opinion now as to whether the IETF ought seek consensus on the > specifics of an API such as you propose. Mainly, I'd be for doing it, > if the API is good and we're not stepping on anyone's toes, and against > dong it if the API is not good and causes liaison issues. (Yes, that's > not an exhaustive characterisation, deliberately:-) > > I would not however support the IETF formally starting out on such work > with a blank sheet of paper. I'm pretty sure we'd end up with an output > that'd make everyone unhappy after loads of effort. > > So, I'd suggest that if you want to pursue this, best would be to get > interested folks working alongside (but outside) the IETF and write > the code you want and then propose that the resulting API be > standardised. "Alongside (but outside)" could mean various things but > what your web page indicates seems like a fine one of those. So, if you > stick with that approach, I'd say come back when you think the specs > at [1] are ready. > > I'd also note that Kathleen's been doing good work on getting some of > the PKCS series under IETF change control. But I think the plan for > PKCS#11 was to have that done in OASIS, [2] so I'd suggest that > chatting with those folks would be sensible, if you've not already. > > Cheers, > S. > > [1] https://github.com/SICA-WG/specs > [2] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 > > From nobody Wed Nov 11 08:51:39 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475951B2C1F for ; Wed, 11 Nov 2015 08:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGXaIouGmELQ for ; Wed, 11 Nov 2015 08:51:36 -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 D52A61B2C18 for ; Wed, 11 Nov 2015 08:51:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D6BEFBE51; Wed, 11 Nov 2015 16:51:33 +0000 (GMT) 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 nYV0vhllbY6J; Wed, 11 Nov 2015 16:51:33 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1D66FBE50; Wed, 11 Nov 2015 16:51:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447260693; bh=Tl0LcwA3YdcTffuGF9sLFfHDwHnOUh+JtsBc7og53NI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=z+Qt7Jk1z/QHe7Cqa7WsN1WSJCOjcAoZYrBdunlYzq0yc1k38gAWbZZLKfcQwxOAj 5Bo3NMMORuZGy+ra85hTDWFwz2AcUVQb708g1pdUSXwHMnx2zrDQ8ehjbvIE5ZOURI bQipABoS3QKgF7MLDpXh6R9WyHy4bGokAhzqWUwM= To: Massimiliano Pala References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> <563F6200.5040107@cs.tcd.ie> <56436981.6070303@openca.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56437214.4090905@cs.tcd.ie> Date: Wed, 11 Nov 2015 16:51:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56436981.6070303@openca.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 16:51:38 -0000 Hi Max, On 11/11/15 16:14, Massimiliano Pala wrote: > Hi Sephen, > > thanks for letting me know your point of view. I would really like to bring > this work to the IETF, as I think it is a practical engineering issue > that could > be addressed by having a standard and related implementations. I already > received some support from several Crypto API vendors and I think we might > see (finally) this happening in the real world. > > As I wrote in my other reply to iang, part of the work is to be sure we > do not > exclude vendors as our purpose is to be available everywhere. I am thinking > about the success of the LDAP API that is implemented on every single > system > I have worked on and by all the vendors I am aware of. Our scope might be > a bit more broad, and we might end up splitting the effort in different > documents (e.g., SSL/TLS, PKIX, SYMCRYPTO, etc.) - I cannot predict it now. > > I am very fond of the IETF and I have been participating to the WGs for > more > than 15 yrs now, but if this is your position we do not have any > alternative but > to work outside the organization for now. I still hope that this will > change at > some point. Sure, I won't repeat all below, but once you've an API defined and some interested folks, then it'll be time to ask more formally about doing work in the IETF. S. > > Thanks Again, > > Cheers, > Max > > > On 11/8/15 9:53 AM, Stephen Farrell wrote: >> Hi Max, >> >> I've no opinion now as to whether the IETF ought seek consensus on the >> specifics of an API such as you propose. Mainly, I'd be for doing it, >> if the API is good and we're not stepping on anyone's toes, and against >> dong it if the API is not good and causes liaison issues. (Yes, that's >> not an exhaustive characterisation, deliberately:-) >> >> I would not however support the IETF formally starting out on such work >> with a blank sheet of paper. I'm pretty sure we'd end up with an output >> that'd make everyone unhappy after loads of effort. >> >> So, I'd suggest that if you want to pursue this, best would be to get >> interested folks working alongside (but outside) the IETF and write >> the code you want and then propose that the resulting API be >> standardised. "Alongside (but outside)" could mean various things but >> what your web page indicates seems like a fine one of those. So, if you >> stick with that approach, I'd say come back when you think the specs >> at [1] are ready. >> >> I'd also note that Kathleen's been doing good work on getting some of >> the PKCS series under IETF change control. But I think the plan for >> PKCS#11 was to have that done in OASIS, [2] so I'd suggest that >> chatting with those folks would be sensible, if you've not already. >> >> Cheers, >> S. >> >> [1] https://github.com/SICA-WG/specs >> [2] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11 >> >> > > From nobody Wed Nov 11 11:00:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC2F1B382D for ; Wed, 11 Nov 2015 11:00: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXpGycuow09B for ; Wed, 11 Nov 2015 11:00:24 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378881B382C for ; Wed, 11 Nov 2015 11:00:24 -0800 (PST) Received: by wmvv187 with SMTP id v187so70162635wmv.1 for ; Wed, 11 Nov 2015 11:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gR66D+UdmGywjymPD6Mau+G+4Ci5RSC/n7d94pbvLIM=; b=Qbv7SQj+X1kSqyeGDO1uJXS0QqjqtAPzq0oYcfGY4BHJEKQVYuczXxwWYsC/uAOIw2 2CSGjpeRHhxoyHebRqVoryE+NAGSQKBfOh2Buj4iyNOtunYtsdYc7rfYuChvApKsRKqy LJm0iNTKkWBo7kMYVYyEvyfIA2vJeSNf360vjqGclkgO2Ux+2kV+uM/34cIgaTro+wPx mdQpT4zL2Zr4spTDIYTwb4lO1BY6xE+N3uU/XLXpj1WVgpZKHB4Rj5ndxdXLTCpYUkR7 l/iQNFtSKVFqcSVAsG4M9L5G5oeodj8W70H1C//iU7juIdVIlqo4X/kUKsZVGMmWcFCK skNQ== MIME-Version: 1.0 X-Received: by 10.194.190.19 with SMTP id gm19mr13593178wjc.0.1447268422767; Wed, 11 Nov 2015 11:00:22 -0800 (PST) Received: by 10.28.52.82 with HTTP; Wed, 11 Nov 2015 11:00:22 -0800 (PST) In-Reply-To: <20151110153349.60826d1c@latte.josefsson.org> References: <56398CBD.9050109@cs.tcd.ie> <87y4ebzb57.fsf@latte.josefsson.org> <563C83BC.2030903@cs.tcd.ie> <5641C55B.4040803@cs.tcd.ie> <87ziymui9z.fsf@latte.josefsson.org> <5641F732.8030600@cs.tcd.ie> <20151110153349.60826d1c@latte.josefsson.org> Date: Wed, 11 Nov 2015 14:00:22 -0500 Message-ID: From: Kathleen Moriarty To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] a few new algs and a bunch of deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 19:00:26 -0000 I do think having this in a WG would be helpful to get the right set of eyes on drafts that may span several areas. A draft that was just posted to the JOSE list could possibly be done in this new group: https://mailarchive.ietf.org/arch/msg/jose/fADOQ-T_fWySMnRbe5QkTqPX7-E Kathleen On Tue, Nov 10, 2015 at 9:33 AM, Simon Josefsson wrote: >> Are there any candidate drafts now? > > The IPSECME WG have accepted a document on key agreement. The TLS WG > (which spawned the CFRG discussion) accepted key agreement, and the > latest WG document RFC 4492bis discuss signatures although I don't > recall any consensus call about adding that. The OpenPGP WG have EdDSA > signatures. The further non-WG documents I can recall now include: > > SSH > --- > > ed25519 sign > https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02 > > curve25519+curve448 kex: > https://tools.ietf.org/html/draft-josefsson-ssh-curves-00 > > missing: ed448 > > PKIX > ---- > > Curve25519+Curve448 namedCurve: > https://tools.ietf.org/html/draft-josefsson-pkix-newcurves > > EdDSA Ed25519(ph) and Ed448(ph) > https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 > > DNS > --- > > Ed25519: > https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03 > > Ed448: > https://tools.ietf.org/html/draft-sury-dnskey-ed448-00 > > JSON > ---- > > There is an unpublished proposal floating around. > > /Simon > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Best regards, Kathleen From nobody Wed Nov 11 12:02:29 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5001B398F for ; Wed, 11 Nov 2015 12:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 c0L8o6ZzEhC8 for ; Wed, 11 Nov 2015 12:02:26 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 35B921B3994 for ; Wed, 11 Nov 2015 12:01:59 -0800 (PST) Received: by oies6 with SMTP id s6so21651444oie.1 for ; Wed, 11 Nov 2015 12:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QBBvF/d0zAVRHrReLmrDpqtEC7wM/kwrcUZ+uZA5mpY=; b=a6xIYu0VpgD1sUP4sLBxoKneroHpoBslnDnSHWI9m0lL0JeHDM5QfQtnltY85wDCby Ng3v0JfvfTQLijBuKOwUdYjgv0gajbEui/Lx8ZvwyGlNT66ScW3N/czGJlnOOVltKHrU qFO5NMZth9c03xtUvfaJZDGXsPy93xxcjIhn/3Nn9IsWPyFqUxtlfnHxrsQ3UICRnI7m xAKqmPM98At6Ovrmn/4o4Y2GPLZ+H0Q7T2AQAq4ykn4vo6Evgw5kNXYFt/vzw4mcTMe0 SFqmE8BEUgBXBldcf4RTUy72GS5fEOy5X36UZVwAfqEryUz+bRolDpQ4mS0Ms0H48D19 GyNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QBBvF/d0zAVRHrReLmrDpqtEC7wM/kwrcUZ+uZA5mpY=; b=bICLfp8N3AI2neijnhZyEE7sABZOukVo/kn3RMYh8GIXSy5CIgdI2uDNNJkpJ7b2lg leI9w8ar/PpcqS/9Fbw/98ByuireexKVKfbqQ8CMTptvKIOa1fmSihn3RE1dfQ+ExC72 nUyD6x1h9FxGL+x++23+TLzmCRfg+9kYBIKR27NInlA3x1fd1rjZLMVOYIV97PVTfvl5 8EKGZCy0hkRjB3yp9zl7L50IQiT0/6wpH77Ha129aK4f930O9ogO+xh+gXz3npyAmYv/ fZk3EnhPZa48DTs/1+WsS/swoBs9IJh3eaQLxChPEG44yM7UMpkxolmzNrOUey82dEg2 cdAw== X-Gm-Message-State: ALoCoQmZtDFQbfKRioO4Vt9suFdE/EDnTvvjmcu5Fp+QpJsxhhBunz0jF081ZNaI5Haos0kYNz1G MIME-Version: 1.0 X-Received: by 10.202.192.67 with SMTP id q64mr6279229oif.60.1447272118409; Wed, 11 Nov 2015 12:01:58 -0800 (PST) Received: by 10.76.168.97 with HTTP; Wed, 11 Nov 2015 12:01:58 -0800 (PST) In-Reply-To: References: <20150826170138.GB9021@mournblade.imrryr.org> <55E028E0.6080803@restena.lu> Date: Thu, 12 Nov 2015 05:01:58 +0900 Message-ID: From: David Bird To: Warren Kumari Content-Type: multipart/alternative; boundary=001a1135b6c88333970524494cdd Archived-At: Cc: Christian Huitema , "saag@ietf.org" Subject: Re: [saag] Would love some feedback on Opportunistic Wireless Encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 20:02:28 -0000 --001a1135b6c88333970524494cdd Content-Type: text/plain; charset=UTF-8 I believe hostapd already has support for an EAP "UNAUTH-TLS" method whereby the client station doesn't authenticate itself, but can "authenticate" the server (much like your typical HTTPS connection). The keying material, like any EAP-TLS based method, comes from the TLS layer. This method could be used with or without a RADIUS server (assuming the authenticator has an EAP engine, like hostapd optionally does). A limitation, however, is that the client can't distinguish between UNAUTH-TLS and other more secure EAP methods until it tries to connect - and will show the network as being secure. And, having a certificate warning/acceptance dialog perhaps with a "You are really joining a public access network, not a 'secure' network" warning might be scary for users. Maybe if the beacon (RSN IE) could indicate 802.1X -and- 'public access'... On Mon, Nov 9, 2015 at 9:27 AM, Warren Kumari wrote: > On Sat, Aug 29, 2015 at 4:13 AM, Christian Huitema > wrote: > > On Friday, August 28, 2015 2:25 AM, Stefan Winter wrote: > >> To: saag@ietf.org > >> Subject: Re: [saag] Would love some feedback on Opportunistic Wireless > >> Encryption > >> > >> Hi, > >> > >> > You are right that there will be some initial legacy issues -- but if > >> > we can convince Windows 10 Mobile, Apple iOS, and Android willing to > >> > include support (which seems likely, "support" is trivial - basically > >> > 1: try the SSID as the passphrase and 2: don't bother showing a lock > >> > icon) > >> > >> Or, for wireless sniffing kit of your choice: > >> > >> 1) try to decrypt with the SSID as the password > >> 2) win! > > > > It is a bit more complicated than that, but not much. With WPA2, the > traffic is not directly encrypted with the password, but instead with a key > derived from the password, the SSID, an Access Point nonce, and a Station > nonce. Even if the password is shared, each client uses a different set of > nonce, and thus a different key. However, the nonce are transmitted in > clear-text during the initial exchange. That means the attack goes as: > > > > 1) Capture the initial exchange between Station and Access point, and > remember the nonce. > > 2) Assume that the SSID is the password and try to derive the per > station key using the nonce. > > 3) Win! > > > > This is in fact the main limitation to Warren's approach. The proposed > OWE system will still be vulnerable to passive listener attacks, and is > thus not much of an improvement over open networks. > > > > Note that this is also a limitation of the "public password" approach, > as in "ask the password to the bartender." We can hypothesize that mass > surveillance systems will quickly build a database linking networks, SSID > and public passwords. After all, the initial WPA2 exchange carries > authentication codes that are the hash of the nonce and the password, which > trivially enables dictionary attacks. That means the procedure will be: > > > > 1) Capture the initial exchange between Station and Access point, and > remember the nonce. > > 2) Retrieve the password associated to the SSID from the database. > > 3) Derive the per station key using the nonce. > > 4) Win! > > > > Thinks would be different if instead of just sending the nonce in clear > text the WPA2 exchange used some variation of Diffie-Hellman or EKE. > Attackers would need to move from "passive listening" to "actively > implement MITM attack," and we believe that might curtail mass surveillance > efforts. But that's not the case. > > > > ... and a quick update (which I thought I'd sent earlier, but > apparently not) - when we wrote the initial document, we were well > aware of the issues with the 4 way handshake, but decided to write the > document in the IETF context anyway. This was because I figured that a > better than nothing approach was, well, better than nothing. We were > aware that the IEEE was the correct layer to get this done, but, well, > I don't participate there much, and figured that it would be a hard / > very slow process. > > Dan Harkins (who most of you know), is an IEEE regular, has nicely > rewritten this into IEEE language, and is getting strong interest / > making progress there. This basically does what everyone has been > suggesting (and I'd originally wanted to do, but couldn't) -- a public > key exchange between the AP and STAtion (think DH). > > This is obviously much much less hacky than the "just pretend that the > user typed the SSID as the passphrase, and don't show any indications > (to avoid having the user believe that they have "security")". > > W > > > > > -- Christian Huitema > > > > > > > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a1135b6c88333970524494cdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe hostapd already has support for an EAP "UNA= UTH-TLS" method whereby the client station doesn't authenticate it= self, but can "authenticate" the server (much like your typical H= TTPS connection). The keying material, like any EAP-TLS based method, comes= from the TLS layer. This method could be used with or without a RADIUS ser= ver (assuming the authenticator has an EAP engine, like hostapd optionally = does).

A limitation, however, is that the client can'= ;t distinguish between UNAUTH-TLS and other more secure EAP methods until i= t tries to connect - and will show the network as being secure. And, having= a certificate warning/acceptance dialog perhaps with a "You are reall= y joining a public access network, not a 'secure' network" war= ning might be scary for users.

Maybe if the be= acon (RSN IE) could indicate 802.1X -and- 'public access'...=C2=A0<= /div>


On Mon, Nov 9, 2015 at 9:27 AM, Warren Kumari &l= t;warren@kumari.net<= /a>> wrote:
On Sat, Aug 29, 201= 5 at 4:13 AM, Christian Huitema
<huitema@microsoft.com> = wrote:
> On Friday, August 28, 2015 2:25 AM, Stefan Winter wrote:
>> To: saag@ietf.org
>> Subject: Re: [saag] Would love some feedback on Opportunistic Wire= less
>> Encryption
>>
>> Hi,
>>
>> > You are right that there will be some initial legacy issues -= - but if
>> > we can convince Windows 10 Mobile, Apple iOS, and Android wil= ling to
>> > include support (which seems likely, "support" is t= rivial - basically
>> > 1: try the SSID as the passphrase and 2: don't bother sho= wing a lock
>> > icon)
>>
>> Or, for wireless sniffing kit of your choice:
>>
>> 1) try to decrypt with the SSID as the password
>> 2) win!
>
> It is a bit more complicated than that, but not much. With WPA2, the t= raffic is not directly encrypted with the password, but instead with a key = derived from the password, the SSID, an Access Point nonce, and a Station n= once. Even if the password is shared, each client uses a different set of n= once, and thus a different key. However, the nonce are transmitted in clear= -text during the initial exchange. That means the attack goes as:
>
> 1) Capture the initial exchange between Station and Access point, and = remember the nonce.
> 2) Assume that the SSID is the password and try to derive the per stat= ion key using the nonce.
> 3) Win!
>
> This is in fact the main limitation to Warren's approach. The prop= osed OWE system will still be vulnerable to passive listener attacks, and i= s thus not much of an improvement over open networks.
>
> Note that this is also a limitation of the "public password"= approach, as in "ask the password to the bartender." We can hypo= thesize that mass surveillance systems will quickly build a database linkin= g networks, SSID and public passwords. After all, the initial WPA2 exchange= carries authentication codes that are the hash of the nonce and the passwo= rd, which trivially enables dictionary attacks. That means the procedure wi= ll be:
>
> 1) Capture the initial exchange between Station and Access point, and = remember the nonce.
> 2) Retrieve the password associated to the SSID from the database.
> 3) Derive the per station key using the nonce.
> 4) Win!
>
> Thinks would be different if instead of just sending the nonce in clea= r text the WPA2 exchange used some variation of Diffie-Hellman or EKE. Atta= ckers would need to move from "passive listening" to "active= ly implement MITM attack," and we believe that might curtail mass surv= eillance efforts. But that's not the case.



... and a quick update (which I thought I'd sent earlier, but
apparently not) - when we wrote the initial document, we were well
aware of the issues with the 4 way handshake, but decided to write the
document in the IETF context anyway. This was because I figured that a
better than nothing approach was, well, better than nothing. We were
aware that the IEEE was the correct layer to get this done, but, well,
I don't participate there much, and figured that it would be a hard / very slow process.

Dan Harkins (who most of you know), is an IEEE regular, has nicely
rewritten this into IEEE language, and is getting strong interest /
making progress there. This basically does what everyone has been
suggesting (and I'd originally wanted to do, but couldn't) -- a pub= lic
key exchange between the AP and STAtion (think DH).

This is obviously much much less hacky than the "just pretend that the=
user typed the SSID as the passphrase, and don't show any indications (to avoid having the user believe that they have "security")"= ;.

W

>
> -- Christian Huitema
>
>
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

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

--001a1135b6c88333970524494cdd-- From nobody Wed Nov 11 13:29:35 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B961B3A6D for ; Wed, 11 Nov 2015 13:29:34 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYys8F5ZF8Yy for ; Wed, 11 Nov 2015 13:29:32 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6211B3A6B for ; Wed, 11 Nov 2015 13:29:32 -0800 (PST) Received: by ykba77 with SMTP id a77so71765174ykb.2 for ; Wed, 11 Nov 2015 13:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o8dM/HstMg75vSgMG2IShiChY9n9N+VMcK/RtJz2xkI=; b=O1eQcmqvtPyaHCArzAecKBHR3J8tuSXLd1LkkPXqXFGCrDbTkV3g9nfyTeZUZibmaJ o77aSnqg9HDRQNCAiCSzu3lIpAlHw8xlpjOOxDmlL0GS63qOoqgTxagAeMVZPDsnXGqz MBoc1jUOSWXDZAxFvbRfwL48PT1CKOgT0kK+IekI7CBDRksqZg9VKIT0YeRr/5Wp6U2g pRc4FOnSk2bp6neaxmWZt1pPMj+s+NfCDgG8QAEGb+8FQ4R8BTew5PUnNfSBHgealIpg cAsVrk09lcRoyJUeJA7VQ5XIfTTIWg1Epqvsl+oRvdS654sZrLwwq0F1m7sl07VOftcq YAsg== X-Received: by 10.129.102.5 with SMTP id a5mr13742482ywc.9.1447277369159; Wed, 11 Nov 2015 13:29:29 -0800 (PST) Received: from [10.185.246.231] (mobile-107-107-59-231.mycingular.net. [107.107.59.231]) by smtp.gmail.com with ESMTPSA id o5sm4114272ywd.46.2015.11.11.13.29.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Nov 2015 13:29:28 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <563F6200.5040107@cs.tcd.ie> Date: Wed, 11 Nov 2015 16:29:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <563DFCFB.8090405@openca.org> <563EDFC6.2050102@openca.org> <563F6200.5040107@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Standard Crypto API + Symmetric Crypto At Rest X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 21:29:34 -0000 Sent from my iPhone > On Nov 8, 2015, at 9:53 AM, Stephen Farrell wr= ote: >=20 >=20 > Hi Max, >=20 > I've no opinion now as to whether the IETF ought seek consensus on the > specifics of an API such as you propose. Mainly, I'd be for doing it, > if the API is good and we're not stepping on anyone's toes, and against > dong it if the API is not good and causes liaison issues. (Yes, that's > not an exhaustive characterisation, deliberately:-) >=20 > I would not however support the IETF formally starting out on such work > with a blank sheet of paper. I'm pretty sure we'd end up with an output > that'd make everyone unhappy after loads of effort. >=20 > So, I'd suggest that if you want to pursue this, best would be to get > interested folks working alongside (but outside) the IETF and write > the code you want and then propose that the resulting API be > standardised. "Alongside (but outside)" could mean various things but > what your web page indicates seems like a fine one of those. So, if you > stick with that approach, I'd say come back when you think the specs > at [1] are ready. >=20 > I'd also note that Kathleen's been doing good work on getting some of > the PKCS series under IETF change control. But I think the plan for > PKCS#11 was to have that done in OASIS, [2] so I'd suggest that > chatting with those folks would be sensible, if you've not already. Yes, PKCS#11 is being actively worked on in OASIS now. The other PKCS stand= ards are in the IETF and I'm working on getting change control transferred t= o the IETF for the remaining two (#1 & #5). Best regards, Kathleen=20 >=20 > Cheers, > S. >=20 > [1] https://github.com/SICA-WG/specs > [2] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dpkcs11 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Nov 13 03:04:16 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF9D1AC3C8 for ; Fri, 13 Nov 2015 03:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F48VnHzctrn9 for ; Fri, 13 Nov 2015 03:04:08 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) (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 E67221AC3CE for ; Fri, 13 Nov 2015 03:04:07 -0800 (PST) Received: from [85.158.138.179] by server-5.bemta-3.messagelabs.com id 5E/65-01748-5A3C5465; Fri, 13 Nov 2015 11:04:05 +0000 X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-14.tower-169.messagelabs.com!1447412645!4268006!1 X-Originating-IP: [195.232.244.134] X-StarScan-Received: X-StarScan-Version: 7.19.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31161 invoked from network); 13 Nov 2015 11:04:05 -0000 Received: from mailout02.vodafone.com (HELO mailout02.vodafone.com) (195.232.244.134) by server-14.tower-169.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Nov 2015 11:04:05 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout02.vodafone.com (Postfix) with ESMTP id 3nxxkY1xXhzbdN0 for ; Fri, 13 Nov 2015 12:04:05 +0100 (CET) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3nxxkY0D60zfZKN for ; Fri, 13 Nov 2015 12:04:05 +0100 (CET) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3nxxkX6z3XzfZ83 for ; Fri, 13 Nov 2015 12:04:04 +0100 (CET) Received: from VOEXC08W.internal.vodafone.com (145.230.101.28) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Nov 2015 12:04:04 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.209]) by voexc08w.internal.vodafone.com ([145.230.101.28]) with mapi id 14.03.0224.002; Fri, 13 Nov 2015 12:04:04 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: "saag@ietf.org" Thread-Topic: [saag] FW: New Version Notification for draft-smith-encrypted-traffic-management-04.txt Thread-Index: AdEeApJrdWZgJJYTR668Xgze2H7OVw== Date: Fri, 13 Nov 2015 11:04:03 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [saag] FW: New Version Notification for draft-smith-encrypted-traffic-management-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 11:04:14 -0000 SGkgYWxsLA0KDQpUaGlzIHZlcnNpb24gaXMgbm93IGluICBzeW5jaCB3aXRoICdFZmZlY3Qgb2Yg dWJpcXVpdG91cyBlbmNyeXB0aW9uJyBkcmFmdCwgYnkgbWFraW5nIHJlZmVyZW5jZSB0byB0aGUg bmV0d29yayBmdW5jdGlvbnMgbGlzdGVkIGluIFsxXS4gQW55IGNvbW1lbnRzIHdlbGNvbWUuDQoN CkFsbCBiZXN0DQpLZXZpbg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtbW0td2ctZWZmZWN0LWVuY3J5cHQvDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiAxMyBOb3ZlbWJlciAyMDE1IDEwOjUwDQpUbzogU21pdGgsIEtl dmluLCAoUiZEKSBWb2RhZm9uZSBHcm91cA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1zbWl0aC1lbmNyeXB0ZWQtdHJhZmZpYy1tYW5hZ2VtZW50LTA0LnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zbWl0aC1lbmNyeXB0ZWQtdHJhZmZpYy1t YW5hZ2VtZW50LTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXZp biBTbWl0aCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1zbWl0aC1lbmNyeXB0ZWQtdHJhZmZpYy1tYW5hZ2VtZW50DQpSZXZpc2lvbjoJMDQNClRpdGxl OgkJTmV0d29yayBtYW5hZ2VtZW50IG9mIGVuY3J5cHRlZCB0cmFmZmljDQpEb2N1bWVudCBkYXRl OgkyMDE1LTExLTEzDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk4DQpV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXNtaXRoLWVuY3J5cHRlZC10cmFmZmljLW1hbmFnZW1lbnQtMDQudHh0DQpTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc21pdGgtZW5jcnlwdGVk LXRyYWZmaWMtbWFuYWdlbWVudC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtc21pdGgtZW5jcnlwdGVkLXRyYWZmaWMtbWFuYWdlbWVudC0wNA0KRGlm ZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zbWl0 aC1lbmNyeXB0ZWQtdHJhZmZpYy1tYW5hZ2VtZW50LTA0DQoNCkFic3RyYWN0Og0KICAgRW5jcnlw dGVkIEludGVybmV0IHRyYWZmaWMgbWF5IHBvc2UgdHJhZmZpYyBtYW5hZ2VtZW50IGNoYWxsZW5n ZXMgdG8NCiAgIG5ldHdvcmsgb3BlcmF0b3JzLiAgVGhpcyBkb2N1bWVudCByZWNvbW1lbmRzIGFw cHJvYWNoZXMgdG8gaGVscA0KICAgbWFuYWdlIGVuY3J5cHRlZCB0cmFmZmljLCB3aXRob3V0IGJy ZWFjaGluZyB1c2VyIHByaXZhY3kgb3Igc2VjdXJpdHkuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg== From nobody Fri Nov 13 12:08:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5541B2D6E for ; Fri, 13 Nov 2015 12:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhgfsFXobO3f for ; Fri, 13 Nov 2015 12:08:45 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C215D1B2D5F for ; Fri, 13 Nov 2015 12:08:45 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 36D0942507B for ; Fri, 13 Nov 2015 20:08:45 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 16BAC42460C for ; Fri, 13 Nov 2015 20:08:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1447445325; bh=nDmUGc6GTxCqU360MVxFLkk+7V0po5qIqBPKUWB6eRQ=; l=3361; h=From:To:Date:From; b=SOvy4cmvvezQXOfWo8hXSdF9W/9fzJEf5vhGHmfLtS/LVBBeq8KIPKYAMUYvO6ezI LQSW8k4wGQE9helCSGJU1abwOt/SP4A9EZu/hNLtLNgttWVGEmOs5lpuV2KctLRByK 5jEuUHSNPZKZhQBI1m3ouDARUMAS86wwo3xsWMVo= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 133E32049 for ; Fri, 13 Nov 2015 20:08:45 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 13 Nov 2015 15:08:44 -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.1076.000; Fri, 13 Nov 2015 15:08:44 -0500 From: "Salz, Rich" To: "saag@ietf.org" Thread-Topic: ACME Report Thread-Index: AdEeTonzPINxHU2HRTCIR0rSM/083A== Date: Fri, 13 Nov 2015 20:08:44 +0000 Message-ID: <6e3d63f1ee52441da137568e610421e2@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.60.4] Content-Type: multipart/alternative; boundary="_000_6e3d63f1ee52441da137568e610421e2usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [saag] ACME Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 20:08:49 -0000 --_000_6e3d63f1ee52441da137568e610421e2usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ACME met in Friday morning. It was very well attended for the last session= of an IETF. I forgot to add up the names on the bluesheets, but it was ov= er 100 people. Richard Barnes presented the changes made to the draft since Prague. He th= en walked through all the open Pull Request and Issues that are opened on G= itHub (at https://github.com/ietf-wg-acme/acme). We discussed and reached = consensus on all of them. All of the non-editorial items will be posted to= the list for confirmation and/or discussion. --_000_6e3d63f1ee52441da137568e610421e2usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ACME met in Friday morning.  It was very well a= ttended for the last session of an IETF.  I forgot to add up the names= on the bluesheets, but it was over 100 people.

 

Richard Barnes presented the changes made to the dra= ft since Prague.  He then walked through all the open Pull Request and= Issues that are opened on GitHub (at https://github.com/ietf-wg= -acme/acme).  We discussed and reached consensus on all of them.&n= bsp; All of the non-editorial items will be posted to the list for confirma= tion and/or discussion.

 

--_000_6e3d63f1ee52441da137568e610421e2usma1exdag1mb1msgcorpak_-- From nobody Wed Nov 18 03:24:05 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793921B2C92 for ; Wed, 18 Nov 2015 03:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf8WCwUtEbYR for ; Wed, 18 Nov 2015 03:24:01 -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 4B2AF1B2C88 for ; Wed, 18 Nov 2015 03:24:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8942BE47 for ; Wed, 18 Nov 2015 11:23:58 +0000 (GMT) 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 he4j15WNbClh for ; Wed, 18 Nov 2015 11:23:58 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 118FBBE32 for ; Wed, 18 Nov 2015 11:23:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447845838; bh=BgwwFR+aIub3KElw3wgZivepaC7aL3+MzyNwcw0LBBY=; h=To:From:Subject:Date:From; b=YTrcQaKdWEqmyL965kDPy+gPR+R7XJEkcBPclk0Mqo8BRVbxlksNpbwa1+pOeJ05v 8k9gMyuY0sRRLo2exZrAqxt4WYOKXQgzKUoTErSYvq5NAxi7DjHcnyi6qKUTDqPoWh v1tUejh+XzvfBaoKUPBcFXomy0fajQaf1fEtQu1M= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564C5FCC.8080107@cs.tcd.ie> Date: Wed, 18 Nov 2015 11:23:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 11:24:03 -0000 Hiya, Following on from the earlier discussion about adding curves etc. a few folks (*) helped Kathleen and I craft an initial cut at charter text. [1] I think we have people (well, mostly Simon:-) to do the editing work for this. If you'd be willing to be a chair, please send an offlist mail to Kathleen and I. If you think this is useful and would review documents please respond to this mail saying so. I'd like to see that we have enough folks interested to make this work. If you have changes to charter text to suggest please do so, preferably in OLD/NEW form. If you think this is a bad idea, I'm sure you'll not be shy in saying so too:-) If there's not enough interest or if there're sound objections then we can abandon the idea and fall back to processing this stuff more slowly and more ad-hoc as AD sponsored drafts. (The main point of curdle is to be more organised and hopefully quicker at this.) Thanks, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and Sean Turner for help with the text. The fault however is mine, if it's bad text or a dumb idea:-) From nobody Wed Nov 18 03:52:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6F1B2D00 for ; Wed, 18 Nov 2015 03:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.486 X-Spam-Level: X-Spam-Status: No, score=-14.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfyHU_LuM0kX for ; Wed, 18 Nov 2015 03:52:56 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453991B2CFF for ; Wed, 18 Nov 2015 03:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3041; q=dns/txt; s=iport; t=1447847576; x=1449057176; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=YsOH5/sutA3Y1/1ZN4NaRVUH0IQn3pW1knofCvNR7kU=; b=kKbw8mJTyAx9ByD6MVm1LTXJwnZrFXtm7fJe340hk0s7qTNFBHcBW9cu oVSjW91NiB4vDBExtgO2TtINvmcEgDy0glKqQHRw5JUnWe4f7t/3FT9Jb kyTJnX4hIjBAJLX1LL/p9ErpAIPMVtRAwY7SH0/OT9tpw2JgGFrD8ntjt U=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AgAvZkxW/xbLJq1ehA5vvmkOgWUXC?= =?us-ascii?q?oVuAoF9FAEBAQEBAQGBCoQ1AQEEAQEBIEsEBhELGAkWCwICCQMCAQIBFTAGAQw?= =?us-ascii?q?GAgEBiCoNrVqQNQEBAQEBAQEBAQEBAQEBAQEBARIFBItShDsBAYM4gUQFlkqCV?= =?us-ascii?q?4FgaogKgVuEQIMCkygfAUOEBT00g0uBQQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,312,1444694400"; d="asc'?scan'208";a="612860198" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2015 11:52:52 +0000 Received: from [10.61.220.78] ([10.61.220.78]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tAIBqqQ9027270; Wed, 18 Nov 2015 11:52:52 GMT To: Stephen Farrell , "saag@ietf.org" References: <564C5FCC.8080107@cs.tcd.ie> From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <564C6693.7000008@cisco.com> Date: Wed, 18 Nov 2015 12:52:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564C5FCC.8080107@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5RWoGifOLoiaVDKnqOeqTOgSajRfgwKxf" Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 11:52:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5RWoGifOLoiaVDKnqOeqTOgSajRfgwKxf Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, Kathleen, Russ, Sean, and others, I really like the charter, and I support the group going forward. I'd be willing to review documents. Just one point about the charter: I could very easily imagine this becoming a standing working group, for instance, as the state of the art advances or where other protocols are identified over time as needing work. I could also very easily see the group closing either before or after completing the proposed charter. My suggestion would be to remain silent on its duration and see how things go. I do have one additional question: what will be the relationship between this group and the CFRG? Eliot On 11/18/15 12:23 PM, Stephen Farrell wrote: > Hiya, > > Following on from the earlier discussion about adding curves > etc. a few folks (*) helped Kathleen and I craft an initial cut > at charter text. [1] > > I think we have people (well, mostly Simon:-) to do the editing > work for this. > > If you'd be willing to be a chair, please send an offlist mail > to Kathleen and I. > > If you think this is useful and would review documents please > respond to this mail saying so. I'd like to see that we have > enough folks interested to make this work. > > If you have changes to charter text to suggest please do so, > preferably in OLD/NEW form. > > If you think this is a bad idea, I'm sure you'll not be shy in > saying so too:-) > > If there's not enough interest or if there're sound objections then > we can abandon the idea and fall back to processing this stuff more > slowly and more ad-hoc as AD sponsored drafts. (The main point of > curdle is to be more organised and hopefully quicker at this.) > > Thanks, > S. > > [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and > Sean Turner for help with the text. The fault however is mine, > if it's bad text or a dumb idea:-) > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --5RWoGifOLoiaVDKnqOeqTOgSajRfgwKxf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWTGaUAAoJEIe2a0bZ0noz35QH/Rp9DrB1XuYthc6vCIyIa3vG usAtrVAAHExsZEY36MNKN27+PkJlC/DdR+L3Zleh/p+ffSX4wED2GDvnG8kvNViw B3dqRyUb3o44yIUcH7h1lOU1GyPOlrZahGS3qGsptwebOnSvM8CbKAw+Vl3LiK6D jm5yCOpwJM+t5gJD/MxQzBu+3EwKFv+M1ZUZDegyi5EiZwTm/v8jXrQ1zyyAlyap pt5MB3lgie1jDZb5VlgVWjBn/R/4UM8u9GwmysH25nSWxxUJ9d9+d4FE0HRr7RzW lt7DZwBVWir15hqChTrl/7W8St93RoWbWzKF28EfAP4jKWMzkLHpOEaNAlbppOM= =3+Rp -----END PGP SIGNATURE----- --5RWoGifOLoiaVDKnqOeqTOgSajRfgwKxf-- From nobody Wed Nov 18 04:13:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12201A010B for ; Wed, 18 Nov 2015 04:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVBltRSGSJUu for ; Wed, 18 Nov 2015 04:13:48 -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 7D1611A0204 for ; Wed, 18 Nov 2015 04:13:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1BC89BE47; Wed, 18 Nov 2015 12:13:46 +0000 (GMT) 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 KI0y4ex94oak; Wed, 18 Nov 2015 12:13:45 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4063FBE3E; Wed, 18 Nov 2015 12:13:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447848825; bh=eaGGfDbT/AdQ1cuAj8C8H3Txi/ggOtEL04r1/T9ZQuk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=szFeWYLSg6aKb+PElOqT4L6f1MLXdHLJt6xNLlcYhpWRFcr2NgVfC6qQGc86T7wE6 4CbIhmTPxsc49dmmlBobapq8cKT2x0mb1ygejHbR2QyiwA7Io9vfgtiPzQPpSQtOyB YDmQsGZ/ImadKHYkpN22A4X++nDJYuZS3fRSo4vg= To: Eliot Lear , "saag@ietf.org" References: <564C5FCC.8080107@cs.tcd.ie> <564C6693.7000008@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564C6B73.60308@cs.tcd.ie> Date: Wed, 18 Nov 2015 12:13:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564C6693.7000008@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DRqjxhC1tXOLEldMlOchr7juS7jrJAHl3" Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 12:13:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DRqjxhC1tXOLEldMlOchr7juS7jrJAHl3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 18/11/15 11:52, Eliot Lear wrote: > Hi Stephen, Kathleen, Russ, Sean, and others, >=20 > I really like the charter, and I support the group going forward. I'd > be willing to review documents. Excellent, thanks. >=20 > Just one point about the charter: I could very easily imagine this > becoming a standing working group, for instance, as the state of the ar= t > advances or where other protocols are identified over time as needing > work. I could also very easily see the group closing either before or > after completing the proposed charter. My suggestion would be to remai= n > silent on its duration and see how things go. Fair point. OTOH, aiming for short-lived is good too, but sure, if there are relevant changes to the state of the art, we'll need to consider those as they arise. I do think we want to keep the list of stuff-that-can-be-added in the charter though so that we can be confident we're only adding stuff that has broad implementer interest. > I do have one additional question: what will be the relationship betwee= n > this group and the CFRG? The way I think of it is that this is taking some specific things from CFRG's recent fine output and instantiating those in IETF protocols, as and when IETF participants want that to be done. I've checked with the CFRG chairs and they said they like the idea too. Cheers, S. >=20 > Eliot >=20 >=20 > On 11/18/15 12:23 PM, Stephen Farrell wrote: >> Hiya, >> >> Following on from the earlier discussion about adding curves >> etc. a few folks (*) helped Kathleen and I craft an initial cut >> at charter text. [1] >> >> I think we have people (well, mostly Simon:-) to do the editing >> work for this. >> >> If you'd be willing to be a chair, please send an offlist mail >> to Kathleen and I. >> >> If you think this is useful and would review documents please >> respond to this mail saying so. I'd like to see that we have >> enough folks interested to make this work. >> >> If you have changes to charter text to suggest please do so, >> preferably in OLD/NEW form. >> >> If you think this is a bad idea, I'm sure you'll not be shy in >> saying so too:-) >> >> If there's not enough interest or if there're sound objections then >> we can abandon the idea and fall back to processing this stuff more >> slowly and more ad-hoc as AD sponsored drafts. (The main point of >> curdle is to be more organised and hopefully quicker at this.) >> >> Thanks, >> S. >> >> [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ >> >> (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and >> Sean Turner for help with the text. The fault however is mine, >> if it's bad text or a dumb idea:-) >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >=20 >=20 --DRqjxhC1tXOLEldMlOchr7juS7jrJAHl3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWTGt3AAoJEC88hzaAX42iyxsH/1W4WZZ/eeUzJVZhlIPQ64Zx UaYSue1O21twSADQ0ectwrUS6VnzSnw3FcaANe9uCDsIjsPlOU1SaMJ31VrQLGHS TXU6GD3TZVsVE2ssxMb+e5w2+s1NM7cTEimYUDNYCN8ArqyF7LBF26b1hww7fjs3 PvlQ474cwv2C4+nlbWCiYXiiHG2wZcX5R7s1qQPhB10BVuAIU2PI7MsGn7eqS3jx 6AN+k44uMrJGP7TNblHnXqX8tYtDRG3S6pNAx1BNI6lp/Iij0EEJ8x2MqEuq03GG 3zJ6OedkzE5PqrNDrhp7YyPxTwSMsElgnV5F/RNBYXr4OVeJmPGBpPv56sjEqW4= =G3K7 -----END PGP SIGNATURE----- --DRqjxhC1tXOLEldMlOchr7juS7jrJAHl3-- From nobody Wed Nov 18 05:11:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893331A8A0F for ; Wed, 18 Nov 2015 05:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1_yXdC_etTw for ; Wed, 18 Nov 2015 05:11:18 -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 1464A1A88B2 for ; Wed, 18 Nov 2015 05:11:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E4A37BE4D for ; Wed, 18 Nov 2015 13:11:16 +0000 (GMT) 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 ewB94cWphJN6 for ; Wed, 18 Nov 2015 13:11:16 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06430BE58 for ; Wed, 18 Nov 2015 13:11:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447852276; bh=U5CvhlNFrPXhLIzNh4S+VKgCRh/aER7tvhLBq5LOmNE=; h=From:Subject:To:Date:From; b=Svijv5yHEuIyU9um1FmKIJiurGdOtv/n00f4WRZKhjlgH3HcendMuF/6g32MEy7uq VAi6QOBtgfkeoV7IbINXUTwKmhrN2xb0vx9En+bz2vzQR79x4rj5vA1Bf4vqCW3O4Z d042W6JG4kMtdgssy+L5vy2EwbukWjr2SU0zXYSo= From: Stephen Farrell To: "saag@ietf.org" Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564C78F2.5050308@cs.tcd.ie> Date: Wed, 18 Nov 2015 13:11:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] TRON submission in 2 weeks... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 13:11:22 -0000 Just a reminder that the TRON workshop [1] initial submission date is December 1st. Please get your good submissions in! (Or hassle folks you know who should be submitting:-) Thanks, S. [1] https://www.internetsociety.org/events/ndss-symposium-2016/tron-workshop-call-papers From nobody Wed Nov 18 09:03:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82441A893C for ; Wed, 18 Nov 2015 09:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNRCrsa0DITS for ; Wed, 18 Nov 2015 09:03:10 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68DF1A890D for ; Wed, 18 Nov 2015 09:03:09 -0800 (PST) X-AuditID: c1b4fb30-f79626d000006adf-8a-564caf4abfbd Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A7.CC.27359.A4FAC465; Wed, 18 Nov 2015 18:03:06 +0100 (CET) Received: from ESESSMB310.ericsson.se ([169.254.10.15]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 18:03:06 +0100 From: John Mattsson To: "saag@ietf.org" Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIiL+yxwHZkFPGkGCMx9vxuLjVw== Date: Wed, 18 Nov 2015 17:03:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.149] Content-Type: multipart/related; boundary="_005_D2726DD940B85johnmattssonericssoncom_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUyM2K7k67Xep8wg70fjSym9HcyOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+eNo6wFe64yVmy7uJylgXHhecYuRk4OCQETiTede9kgbDGJ C/fWA9lcHEIChxklXq3YwgrhLGGU2D7lJVgVm4CBxNw9DWC2iICyxPI/z9lBbGGg+Mal25gg 4oYSB3ftZ4aw9SR6ZnaA1bMIqEo82AhRwytgLnG44Q4riM0ItPn7qTVgcWYBcYlbT+YzQVwk IvHw4mmo60QlXj7+B1TPwSEKNHPPckmIsJLE2sPbWSBaKyT+ztvMAjFeUOLkzCcsExiFZyGZ OgtJ2SwkZRDxGIkTpz+zzwLawCygKbF+lz5EWFFiSvdDdghbQ6J1zlwo21pi5d0l7JhqfCRe fd7ACmE7Srw42A5kcwHZxxklNi+ZDFVkJNG3YyoTNs1zWh4xQ9zgKHH9fxxEGKj31gpZmNaZ NxtQtC5gFF7FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZhMDm75bbCD8eVzx0OMAhyMSjy8 BRu9w4RYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCURXu1qnzAh3pTEyqrUovz4otKc1OJDjNIc LErivM1MD0KFBNITS1KzU1MLUotgskwcnFINjNI/K05/MArJq8112yt3yM7iTd+8/ZI1ZxKC 3lzZuaLrZeDvA/Mr7C1371R6z7hG9eS88/evaZiWhzdkmWkFcJSE7Wi3+n03XaLQL87td9cT kUvsS+PrGcyv/2455srJyBuZt3xG0wGlyybmZ+KnB60vfPm1482u72d3Pn7J15JeyHxfKYc/ XomlOCPRUIu5qDgRAFLUd/kuAwAA Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:03:13 -0000 --_005_D2726DD940B85johnmattssonericssoncom_ Content-Type: multipart/alternative; boundary="_000_D2726DD940B85johnmattssonericssoncom_" --_000_D2726DD940B85johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkV4Y2VsbGVudCEgV2VsbCBuZWVkZWQgYW5kIGEgZ29vZCB3cml0dGVuIGNoYXJ0ZXIu DQoNCkkgYWdyZWUgd2l0aCBFbGlvdHMgZWFybGllciBjb21tZW50cywgYW5kIEkgaGF2ZSBvbmUg YWRkaXRpb25hbCBzdWdnZXN0aW9uLg0KDQpUaGUgY3VycmVudCBjaGFydGVyIG9ubHkgYWxsb3dz IHRoZSB3b3JraW5nIGdyb3VwIHRvIGludHJvZHVjZSBuZXcgbWVjaGFuaXNtcyAod2hpY2ggd291 bGQgdGhlbiBiZSBNQVkgc3VwcG9ydCkgb3IgZGVwcmVjYXRlIG9sZCBhbGdvcml0aG1zICh3aGlj aCB3b3VsZCB0aGVuIGJlIE1VU1QgTk9UIHN1cHBvcnQ/KS4gSSB0aGluayB0aGUgZ3JvdXAgc2hv dWxkIGFsc28gaGF2ZSB0aGUgcG9zc2liaWxpdHkgdG8gY3JlYXRlIHByb2ZpbGVzIHNpbWlsYXIg dG8gUkZDNzMyMSwgUkZDNDMwN2JpcywgYW5kIFRMUyAxLjMgU2VjdGlvbiA4IChpLmUgTVVTVCwg U0hPVUxELCBNQVksIFNIT1VMRCBOT1QsIE1VU1QgTk9UIHN1cHBvcnTigKYpLiBJIGhhdmUgcmVj ZW50bHkgZHJpdmVuIGEgcHJvZmlsZSB1cGRhdGUgb2YgYWxsIDNHUFAgdXNhZ2Ugb2YgSUVURiBT ZWN1cml0eSBQcm90b2NvbHMgYXMgd2VsbCBhcyBhbiBpbnRlcm5hbCB1cGRhdGUgb2YgRXJpY3Nz b24ncyB1c2FnZSBvZiBzZWN1cml0eSBtZWNoYW5pc21zLiBJbXBsZW1lbnRhdGlvbiBSZXF1aXJl bWVudHMgYW5kIFVzYWdlIEd1aWRhbmNlIGZvciBhdCBsZWFzdCBTU0ggYW5kIFBLSVggd291bGQg YmUgdmVyeSB1c2VmdWwgdG8gaGF2ZS4NCg0KU29tZSBlZGl0b3JpYWxzOg0K4oCcYW5kIEpTT07i gJ0gLT4gImFuZCBKT1NFIg0K4oCcQUVTLUNDTVs0XeKAnSAtPiDigJxBRVMtQ0NNIFs0XSINCg0K Q2hlZXJzLA0KSm9obg0KDQpPbiAxMS8xOC8xNSAxMjoyMyBQTSwgU3RlcGhlbiBGYXJyZWxsIHdy b3RlOg0KPiBIaXlhLA0KPg0KPiBGb2xsb3dpbmcgb24gZnJvbSB0aGUgZWFybGllciBkaXNjdXNz aW9uIGFib3V0IGFkZGluZyBjdXJ2ZXMNCj4gZXRjLiBhIGZldyBmb2xrcyAoKikgaGVscGVkIEth dGhsZWVuIGFuZCBJIGNyYWZ0IGFuIGluaXRpYWwgY3V0DQo+IGF0IGNoYXJ0ZXIgdGV4dC4gWzFd DQo+DQo+IEkgdGhpbmsgd2UgaGF2ZSBwZW9wbGUgKHdlbGwsIG1vc3RseSBTaW1vbjotKSB0byBk byB0aGUgZWRpdGluZw0KPiB3b3JrIGZvciB0aGlzLg0KPg0KPiBJZiB5b3UnZCBiZSB3aWxsaW5n IHRvIGJlIGEgY2hhaXIsIHBsZWFzZSBzZW5kIGFuIG9mZmxpc3QgbWFpbA0KPiB0byBLYXRobGVl biBhbmQgSS4NCj4NCj4gSWYgeW91IHRoaW5rIHRoaXMgaXMgdXNlZnVsIGFuZCB3b3VsZCByZXZp ZXcgZG9jdW1lbnRzIHBsZWFzZQ0KPiByZXNwb25kIHRvIHRoaXMgbWFpbCBzYXlpbmcgc28uIEkn ZCBsaWtlIHRvIHNlZSB0aGF0IHdlIGhhdmUNCj4gZW5vdWdoIGZvbGtzIGludGVyZXN0ZWQgdG8g bWFrZSB0aGlzIHdvcmsuDQo+DQo+IElmIHlvdSBoYXZlIGNoYW5nZXMgdG8gY2hhcnRlciB0ZXh0 IHRvIHN1Z2dlc3QgcGxlYXNlIGRvIHNvLA0KPiBwcmVmZXJhYmx5IGluIE9MRC9ORVcgZm9ybS4N Cj4NCj4gSWYgeW91IHRoaW5rIHRoaXMgaXMgYSBiYWQgaWRlYSwgSSdtIHN1cmUgeW91J2xsIG5v dCBiZSBzaHkgaW4NCj4gc2F5aW5nIHNvIHRvbzotKQ0KPg0KPiBJZiB0aGVyZSdzIG5vdCBlbm91 Z2ggaW50ZXJlc3Qgb3IgaWYgdGhlcmUncmUgc291bmQgb2JqZWN0aW9ucyB0aGVuDQo+IHdlIGNh biBhYmFuZG9uIHRoZSBpZGVhIGFuZCBmYWxsIGJhY2sgdG8gcHJvY2Vzc2luZyB0aGlzIHN0dWZm IG1vcmUNCj4gc2xvd2x5IGFuZCBtb3JlIGFkLWhvYyBhcyBBRCBzcG9uc29yZWQgZHJhZnRzLiAo VGhlIG1haW4gcG9pbnQgb2YNCj4gY3VyZGxlIGlzIHRvIGJlIG1vcmUgb3JnYW5pc2VkIGFuZCBo b3BlZnVsbHkgcXVpY2tlciBhdCB0aGlzLikNCj4NCj4gVGhhbmtzLA0KPiBTLg0KPg0KPiBbMV0g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1pZXRmLWN1cmRsZS8NCj4N Cj4gKCopIFRoYW5rcyB0byBTaW1vbiBKb3NlZnNzb24sIFlvYXYgTmlyLCBSdXNzIEhvdXNsZXkg YW5kDQo+IFNlYW4gVHVybmVyIGZvciBoZWxwIHdpdGggdGhlIHRleHQuIFRoZSBmYXVsdCBob3dl dmVyIGlzIG1pbmUsDQo+IGlmIGl0J3MgYmFkIHRleHQgb3IgYSBkdW1iIGlkZWE6LSkNCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2FhZyBt YWlsaW5nIGxpc3QNCj4gc2FhZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NhYWcNCj4NCg0KDQpKT0hOIE1BVFRTU09ODQpNU2MgRW5naW5lZXJpbmcg UGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWluaXN0cmF0aW9uIGFuZCBFY29ub21pY3MNCkVyaWNz c29uIElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0b3INClNlbmlvciBSZXNlYXJjaGVyLCBTZWN1cml0 eQ0KDQpFcmljc3NvbiBBQg0KRXJpY3Nzb24gUmVzZWFyY2gNCkbDpHLDtmdhdGFuIDYNClNFLTE2 NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbg0KUGhvbmUgKzQ2IDEwIDcxIDQzIDUwMQ0KU01TL01NUyAr NDYgNzYgMTEgNTMgNTAxDQpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTxtYWlsdG86am9obi5t YXR0c3NvbkBlcmljc3Nvbi5jb20+DQp3d3cuZXJpY3Nzb24uY29tPGh0dHA6Ly93d3cuZXJpY3Nz b24uY29tLz4NCg0KDQpbaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vXTxodHRwOi8vd3d3LmVyaWNz c29uLmNvbS8+DQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXR3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5j b20vZW1haWxfZGlzY2xhaW1lcj4NCg0K --_000_D2726DD940B85johnmattssonericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <64C6D3883BA1C449A11B0D70DFAD990D@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyI+DQo8ZGl2PkhpLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RXhjZWxsZW50 ISBXZWxsIG5lZWRlZCBhbmQgYSBnb29kIHdyaXR0ZW4gY2hhcnRlci48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PkkgYWdyZWUgd2l0aCBFbGlvdHMgZWFybGllciBjb21tZW50cywgYW5k IEkgaGF2ZSBvbmUgYWRkaXRpb25hbCBzdWdnZXN0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VGhlIGN1cnJlbnQgY2hhcnRlciBvbmx5IGFsbG93cyB0aGUgd29ya2luZyBncm91 cCB0byBpbnRyb2R1Y2UgbmV3IG1lY2hhbmlzbXMgKHdoaWNoIHdvdWxkIHRoZW4gYmUgTUFZIHN1 cHBvcnQpIG9yIGRlcHJlY2F0ZSBvbGQgYWxnb3JpdGhtcyAod2hpY2ggd291bGQgdGhlbiBiZSBN VVNUIE5PVCBzdXBwb3J0PykuIEkgdGhpbmsgdGhlIGdyb3VwIHNob3VsZCBhbHNvIGhhdmUgdGhl IHBvc3NpYmlsaXR5IHRvIGNyZWF0ZSBwcm9maWxlcyBzaW1pbGFyDQogdG8gUkZDNzMyMSwgUkZD NDMwN2JpcywgYW5kIFRMUyAxLjMgU2VjdGlvbiA4IChpLmUgTVVTVCwgU0hPVUxELCBNQVksIFNI T1VMRCBOT1QsIE1VU1QgTk9UIHN1cHBvcnTigKYpLiBJIGhhdmUgcmVjZW50bHkgZHJpdmVuIGEg cHJvZmlsZSB1cGRhdGUgb2YgYWxsIDNHUFAgdXNhZ2Ugb2YgSUVURiBTZWN1cml0eSBQcm90b2Nv bHMgYXMgd2VsbCBhcyBhbiBpbnRlcm5hbCB1cGRhdGUgb2YgRXJpY3Nzb24ncyB1c2FnZSBvZiBz ZWN1cml0eSBtZWNoYW5pc21zLiZuYnNwOzxzcGFuIHN0eWxlPSJsaW5lLWhlaWdodDogMS4yMTQ7 IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjUzLCAyNDUpOyI+SW1wbGVt ZW50YXRpb24NCiBSZXF1aXJlbWVudHMgYW5kIFVzYWdlIEd1aWRhbmNlIGZvciBhdCBsZWFzdCBT U0ggYW5kIFBLSVggd291bGQgYmUgdmVyeSB1c2VmdWwgdG8gaGF2ZS48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Tb21lIGVk aXRvcmlhbHM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiPuKAnDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ1BUIE1vbm8nLCBNb25hY28sIG1v bm9zcGFjZTsgbGluZS1oZWlnaHQ6IDEuMjE0OyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1MywgMjQ1KTsiPmFuZCBKU09OPC9zcGFuPuKAnSAtJmd0OyAmcXVvdDthbmQg Sk9TRSZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij7igJw8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdQVCBNb25vJywgTW9uYWNvLCBt b25vc3BhY2U7IGxpbmUtaGVpZ2h0OiAxLjIxNDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTMsIDI0NSk7Ij5BRVMtQ0NNWzRdPC9zcGFuPuKAnSAtJmd0OyDigJw8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6ICdQVCBNb25vJywgTW9uYWNvLCBtb25vc3BhY2U7IGxpbmUt aGVpZ2h0OiAxLjIxNDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTMs IDI0NSk7Ij5BRVMtQ0NNDQogWzRdPC9zcGFuPiZxdW90OzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5Kb2huPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHByZSBjbGFzcz0i d29yZHdyYXAiIHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFk ZGluZzogMHB4OyBib3JkZXI6IDBweDsgZm9udC1zdHJldGNoOiBpbmhlcml0OyBmb250LXNpemU6 IDEycHg7IGxpbmUtaGVpZ2h0OiAxOHB4OyBmb250LWZhbWlseTogQ291cmllciwgJ0NvdXJpZXIg TmV3JywgbW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7IHdoaXRlLXNwYWNlOiBw cmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0ibWFy Z2luLWJvdHRvbTogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBmb250LXN0cmV0Y2g6 IGluaGVyaXQ7IGZvbnQtc2l6ZTogMTNweDsgbGluZS1oZWlnaHQ6IGluaGVyaXQ7IGZvbnQtZmFt aWx5OiBDb3VyaWVyLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiBi YXNlbGluZTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij5P biAxMS8xOC8xNSAxMjoyMyBQTSwgU3RlcGhlbiBGYXJyZWxsIHdyb3RlOg0KJmd0OyBIaXlhLA0K Jmd0Ow0KJmd0OyBGb2xsb3dpbmcgb24gZnJvbSB0aGUgZWFybGllciBkaXNjdXNzaW9uIGFib3V0 IGFkZGluZyBjdXJ2ZXMNCiZndDsgZXRjLiBhIGZldyBmb2xrcyAoKikgaGVscGVkIEthdGhsZWVu IGFuZCBJIGNyYWZ0IGFuIGluaXRpYWwgY3V0DQomZ3Q7IGF0IGNoYXJ0ZXIgdGV4dC4gWzFdDQom Z3Q7DQomZ3Q7IEkgdGhpbmsgd2UgaGF2ZSBwZW9wbGUgKHdlbGwsIG1vc3RseSBTaW1vbjotKSB0 byBkbyB0aGUgZWRpdGluZw0KJmd0OyB3b3JrIGZvciB0aGlzLg0KJmd0Ow0KJmd0OyBJZiB5b3Un ZCBiZSB3aWxsaW5nIHRvIGJlIGEgY2hhaXIsIHBsZWFzZSBzZW5kIGFuIG9mZmxpc3QgbWFpbA0K Jmd0OyB0byBLYXRobGVlbiBhbmQgSS4NCiZndDsNCiZndDsgSWYgeW91IHRoaW5rIHRoaXMgaXMg dXNlZnVsIGFuZCB3b3VsZCByZXZpZXcgZG9jdW1lbnRzIHBsZWFzZQ0KJmd0OyByZXNwb25kIHRv IHRoaXMgbWFpbCBzYXlpbmcgc28uIEknZCBsaWtlIHRvIHNlZSB0aGF0IHdlIGhhdmUNCiZndDsg ZW5vdWdoIGZvbGtzIGludGVyZXN0ZWQgdG8gbWFrZSB0aGlzIHdvcmsuDQomZ3Q7DQomZ3Q7IElm IHlvdSBoYXZlIGNoYW5nZXMgdG8gY2hhcnRlciB0ZXh0IHRvIHN1Z2dlc3QgcGxlYXNlIGRvIHNv LA0KJmd0OyBwcmVmZXJhYmx5IGluIE9MRC9ORVcgZm9ybS4NCiZndDsNCiZndDsgSWYgeW91IHRo aW5rIHRoaXMgaXMgYSBiYWQgaWRlYSwgSSdtIHN1cmUgeW91J2xsIG5vdCBiZSBzaHkgaW4NCiZn dDsgc2F5aW5nIHNvIHRvbzotKQ0KJmd0Ow0KJmd0OyBJZiB0aGVyZSdzIG5vdCBlbm91Z2ggaW50 ZXJlc3Qgb3IgaWYgdGhlcmUncmUgc291bmQgb2JqZWN0aW9ucyB0aGVuDQomZ3Q7IHdlIGNhbiBh YmFuZG9uIHRoZSBpZGVhIGFuZCBmYWxsIGJhY2sgdG8gcHJvY2Vzc2luZyB0aGlzIHN0dWZmIG1v cmUNCiZndDsgc2xvd2x5IGFuZCBtb3JlIGFkLWhvYyBhcyBBRCBzcG9uc29yZWQgZHJhZnRzLiAo VGhlIG1haW4gcG9pbnQgb2YNCiZndDsgY3VyZGxlIGlzIHRvIGJlIG1vcmUgb3JnYW5pc2VkIGFu ZCBob3BlZnVsbHkgcXVpY2tlciBhdCB0aGlzLikNCiZndDsNCiZndDsgVGhhbmtzLA0KJmd0OyBT Lg0KJmd0Ow0KJmd0OyBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRl ci1pZXRmLWN1cmRsZS8NCiZndDsNCiZndDsgKCopIFRoYW5rcyB0byBTaW1vbiBKb3NlZnNzb24s IFlvYXYgTmlyLCBSdXNzIEhvdXNsZXkgYW5kDQomZ3Q7IFNlYW4gVHVybmVyIGZvciBoZWxwIHdp dGggdGhlIHRleHQuIFRoZSBmYXVsdCBob3dldmVyIGlzIG1pbmUsDQomZ3Q7IGlmIGl0J3MgYmFk IHRleHQgb3IgYSBkdW1iIGlkZWE6LSkNCiZndDsNCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiZndDsgc2FhZyBtYWlsaW5nIGxpc3QNCiZndDsg c2FhZ0BpZXRmLm9yZw0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NhYWcNCiZndDs8L3ByZT48L3ByZT4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IG1hcmdpbjogMGNtIDBjbSAxMnB0OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+PGltZyB3aWR0aD0iMjU1IiBoZWlnaHQ9IjMi IGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iY2lkOkZEQjgwNTlBLTJBRjctNDczMi04RkJCLTEyQTk0 QjI5QzkwRSIgYWx0PSJsaW5lIiB0eXBlPSJpbWFnZS9wbmciPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IG1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsiPkpPSE4g TUFUVFNTT048bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyI+TVNjIEVuZ2luZWVyaW5nIFBoeXNpY3MsIE1TYyBC dXNpbmVzcyBBZG1pbmlzdHJhdGlvbiBhbmQgRWNvbm9taWNzPC9zcGFuPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+PHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7Ij48Zm9udCBmYWNlPSJBcmlhbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTNweDsiPjxiPkVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29vcmRp bmF0b3I8L2I+PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHNp emU9IjMiPiZuYnNwOzwvZm9udD48L3NwYW4+PGIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYig1MSwgNTEsIDUxKTsiPjxicj4NClNlbmlvciBSZXNlYXJjaGVyLCBTZWN1 cml0eTwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoNTEsIDUxLCA1MSk7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0 OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7 Ij5Fcmljc3NvbiBBQjxicj4NCkVyaWNzc29uIFJlc2VhcmNoPGJyPg0KRsOkcsO2Z2F0YW4gNjxi cj4NClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbjxicj4NClBob25lICYjNDM7NDYgMTAgNzEg NDMgNTAxPGJyPg0KU01TL01NUyAmIzQzOzQ2IDc2IDExIDUzIDUwMTxicj4NCjxhIGhyZWY9Im1h aWx0bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7Ij48 c3BhbiBzdHlsZT0iY29sb3I6IGJsdWU7Ij5qb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTwvc3Bh bj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoNTEsIDUxLCA1MSk7Ij48YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8iIHN0eWxl PSJjb2xvcjogcHVycGxlOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBibHVlOyI+d3d3LmVyaWNzc29u LmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 Ij48YnI+DQo8YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vIiB0 YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsdWU7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNTAwIiBoZWlnaHQ9 IjgxIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDoyN0IxNzY0Qy1DQTMyLTQ5OTEtQkE5NC1E NURERkU4RjFGMTMiIGFsdD0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vIiB0eXBlPSJpbWFnZS9w bmciPjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDhwdDsg Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyI+ VGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNl aXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dA0KIGF0PGEgaHJlZj0i aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgdGl0bGU9Imh0dHA6Ly93 d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHN0eWxlPSJjb2xvcjogcHVycGxlOyI+ PHNwYW4gc3R5bGU9ImNvbG9yOiBibHVlOyI+d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFp bWVyPC9zcGFuPjwvYT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_D2726DD940B85johnmattssonericssoncom_-- --_005_D2726DD940B85johnmattssonericssoncom_ Content-Type: image/png; name="13DEFB94-F735-49B0-8196-BDB5C9017A32[17].png" Content-Description: 13DEFB94-F735-49B0-8196-BDB5C9017A32[17].png Content-Disposition: inline; filename="13DEFB94-F735-49B0-8196-BDB5C9017A32[17].png"; size=2991; creation-date="Wed, 18 Nov 2015 17:03:06 GMT"; modification-date="Wed, 18 Nov 2015 17:03:06 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAP8AAAADCAIAAADTOk7/AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAABKUlEQVRI De1TMU4DQQycu5yokNKglEhIfIEf8JEoHSU/gAfkATQ8gMcgGigR0CYSDVRhzdheL7sogT6602o1 6xmPvb67TkQAvKzu7l+v1x9PSbovWwm9A+4R1EhCFhjbB2UapUwTJqHPwU1lpYlhZSaRWAU3stOf KYIeXNLpnjFBOXaQiHswH02guChbk8bzT5NGSZNdnqViCEonohMBX4HepwIW/J/6lV5nbaWsEMs1 zp61lSqNJUCSZQEpWavoRSa2BkCB7wEG0UsyPoCySmBHshPOS1CxJoMoRf1Plh4ps3KuL7VUVumb uLdkrH7hB2qrAj7HNxfTxTkBO9Tn4e3q/fPR8biPE9jjCfAfeL689Qvmr/90Nj86PNvjO49XGydQ JnCynDv+BsiTWPQxCGmXAAAAAElFTkSuQmCC --_005_D2726DD940B85johnmattssonericssoncom_ Content-Type: image/png; name="D377E800-0A1A-43D3-AF5E-165F697789B5[17].png" Content-Description: D377E800-0A1A-43D3-AF5E-165F697789B5[17].png Content-Disposition: inline; filename="D377E800-0A1A-43D3-AF5E-165F697789B5[17].png"; size=5392; creation-date="Wed, 18 Nov 2015 17:03:06 GMT"; modification-date="Wed, 18 Nov 2015 17:03:06 GMT" Content-ID: <27B1764C-CA32-4991-BA94-D5DDFE8F1F13> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAfQAAABRCAIAAACrEsM0AAAKQWlDQ1BJQ0MgUHJvZmlsZQAASA2d lndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji 1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE 9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX 5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjASh XJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHim Z+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW 5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC0 3pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TM zAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRo dV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2 g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQ OBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhH wsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQ DqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJ NhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/B c/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7Y QbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxF QtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6f J18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIl pSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyT jLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uu q43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoL tQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0sv WC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+ 41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIud Ft0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtO u8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX 1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrP C16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARG BFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJF REPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH 4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN 8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqw K10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTk muRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99u it7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/nd zPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqv akfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/ Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4 H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HO FZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9 jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3R B6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0 RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk 03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/syOll+AAAKiklEQVR4 Ae2dPWwURxiGA0oDCQSUVEFA6OwKE4gLBATrnEDHXZtItpFIEWEJJ1RGQoCQ7Cr8JEYpEsk2Rdo7 l4l8AgJKARicBrvjJ6FKpPAnUpLXfNHcaPe8d2u45Zh9rNNpdvab2ZlnrHe/+3ZmdtmzZ8/e4A8C EIAABMIisDys7tAbCEAAAhBYIIC4838AAQhAIEACiHuAg0qXIAABCCDu/A9AAAIQCJAA4h7goNIl CEAAAog7/wMQgAAEAiSAuAc4qHQJAhCAAOLO/wAEIACBAAkg7gEOKl2CAAQg8ObrguDO/b8r1ZkH j56qwbu7O3d3d7wuLaedEIAABLInsKz9tx+YKF+uVGenqtd9OgOlneMjB/wc0hCAAAQg4Ai0r7hf vDo/WblSmZ558HjBW4//Sdwl8fF8ciAAAQhAoO3EXeGXs+d/UQRGieThUWTmwuRwsg1nIQABCOST QLvE3B88/nei/Otk+crs/L18jgS9hgAEIPASCbx6ca8bUn+JPaQqCEAAAjkk8MrEvWFIveFg9Bd3 NLTBAAIQgEA+CWQt7s2H1JPHY6hvD09TkxFxFgIQyDOBjMT9ZYXUP1j3XrGw9VDfp0rkedjoOwQg AIFkAlmIu56RlgbPNpz9ktxQ+en7Cluk7MlmnIUABCAAARHIYirkltLRJc+B6erYID+92LttzaoV DBgEIAABCDRJoOWeu2R9CcpO+KXJ8cMMAhCAQF0CLRd32w2m7rXjmWtWrSz2btU0mPjWMbpDPJ8F f/edVW8XC108TY3TIwcCEICAI9BycXdXSk5IzaXp8fCLIvVarao1q37IXvvMaGcClqcmI+UsBCCQ ZwJZxNw39R72pdnHrfDLQki9sDUy+0WzayrTCwqu6fC+vZ8+PfyZJkT6OaQhAAEIQMAIZCHuiqj0 9I36+39Z+EWyruelkZGQnz5Vvallq5H8+CF7y8SZkAMBCEDACGQRlpGC366e0tYxv8//IVnf3LE+ HjG3kLo03b8HMEgQgAAEILA0AlmIu1qmiYx1QygWUl/afmF6srq0PlMKAhCAQPAEMhL3CEcLqcdf wRExSz4cKG1PNuAsBCAAgdwSyFrcLaSe8AqOZkZCsR09TWW1ajOssIEABPJJICNxV/ilyVdwJA+D wvf9pR0DpV0sWE0GxVkIQCDnBLIQ9/hsmbTQWbCalhj2EIBAzglkMRUyYZ57Q/rsF9YQEQYQgAAE 4gRa7rlrFdJiK5jirXE5iy1YdQYkIAABCEAggUDLxT3h2vFTCr9oEwJ565EFq7K0t/E9fPxE6Y8/ 6hjq30vYPQ6QHAhAAAJGoOXivmb1yoask/cLW3gSOz3jL27Sr4Gp6o0L54+g7w3ZYgABCOSTQBYx 957+0cW2iNlX2FZ3i0dFcuSqa2+ZhJDOsYPF44OlfA4bvYYABCCQTKDlnrsuXx4b6ukb0ZwZ1xRF XRL2C5Or7hu7UpHEpWuL7ikWseQQAhCAQN4IZCHuCp7cLJ/U8qXZuQV9147tdfcLmyj/pr188zYA 9BcCEIBAKwhkIe7Wbi0oja8plYceD6k32U/2lmkSFGYQgEAOCWQn7j7cZkLqvn3d9FDfJ3XzyYQA BCAAgUzF3fYLazKknjA2Ctlrb5n4q/gSinAKAhCAQK4IZCTuCr8cH5t68ZC6ZtdoM8h4eCdXY0Zn IQABCDQkkIW461FqafDbhk1JMNAD2IXZNb3bmNieQIlTEIAABByBLOa5r+3+0l+C5K7dMKHwi5x0 yXp8wWrDshhAAAIQyDOBlnvuWr6UVtltweq+whbCL3n+16TvEIDAixBoubinahz7haXChTEEIACB xQi0XNyb2VtGUZfF9gtbrN3kQwACEIBAAoGWi7uehcofr7u3jIVfFFKPL1hNaDGnIAABCECgIYEs Hqhqentp8Iyv74vtF9awuRhAAAIQgEAzBLIQd2uHprrPzt1VlKarYyOzX5oZG2wgAAEILJlAduK+ 5CZSEAIQgAAE0hJYnrYA9hCAAAQg0P4EEPf2HyNaCAEIQCA1AcQ9NTIKQAACEGh/Aoh7+48RLYQA BCCQmgDinhoZBSAAAQi0PwHEvf3HiBZCAAIQSE0AcU+NjAIQgAAE2p/Ay9l+QAuUHjx66vc2+TVJ 9komvWxPRbSgqatzo+1A4OdrudPu7s7kfBVXJRevzllVdV+97beKNAQgAIGcEEixiGlZZ38cyoXJ Yel4T/+ov7uAzLRvjN6EN1DaqbQVNEsdHh8rnzhXiVT1bG5Sd4ievlF/f2DVrFIT5ctfjf4Uz1cN yj9z/me/Kt0Mxke/sFuCa7C7tLXz2MHi8cGSX4o0BCAAgcAIpPbcpZv+Ro9+2kcjLd5/5Mf4u5N8 OZbPro9cfsm6ypYGz5qC2yXcTwGn7JF83SScsus2MDt3T8VV1f7hH26WT/qNOXGuvLt72M8hDQEI QCBsAqnF/fTw5wkhFzngCq309I2YXmszGd9YwRMnx/Lrh/r2GFwLqti3XH4nzarKvetDyu7nq6Be tG3FrSoZbyp8bfouZ99+NJiBKtHHb4nl8w0BCEAgVAKpH6jOzt81rbTvCJfnmbecTEf0VMFxs5dS O2VXju0jJllXWuq8qfewvHXdHvTGVIXjrYgOLV+VK18XMjdfpawqZTpBtwZYQcuU826HfEMAAhDI A4HUnrtk1+ciV90/VFDbDqW546MH/FNKO83dV/gwckqHcsAVyTEzOfj6SJfHRw5Iu83fV3HLV9Bc z1qthq7ODa6qjevetfSla/MuU8Zy5HUz0LfLJAEBCEAgbAKpxV2Cu/H9/zU0AY3c6jWr3ooYuAD9 7PyfkVM6VM3y0xVsqUzPmFcuOdarPCT6uhlMVq64fD2PNWdfpVxo3k9rV2FXvyyl7yril3JnSUAA AhAIkkDqsIzeh6epJu4TgSJHXlpsmZLjyFnnbk9Vr1tQPmKgcI1c9X+ufq+3edgp026Fd5R/u3pK Bpbv3SfuuR8EU9Ubdta58HY41L9XvyRkpoeulsM3BCAAgbAJpPbcJdkudC40credE22kBkq7LHQj R1uK7OOTNEumFSFR5pbSUfcjQHXenv6mOPjd2tUrNnes19lLV2+5ggq1FwtbpdcSeqfj8s1V3CIt mmYjB79SnbUbhnRcbXDFlVA4Xgby3O0HgX+KNAQgAIEgCaQW90jkWs54RNylpPK75ZtLSWUsCfbB lceG3Cv3/Kqk+BL0iPjqTqCPhdr9SuyOonk7mo0jQdfHgvWysVi/2uDbKy3nXQGfSP0RGw4hAAEI BEMghbgrch3vtim7H+OWzUBp+8PHT5QwR9sKmqVkV0uKKtWZqerNO/f/sgrtxXtyrv0HoYqzmwOu B6qaouMurbiQ3TBUlSZH6g4hn90up3pUibvZ+A2WcXnskP3mcNEhVycJCEAAAoERSLFCNbCe0x0I QAACARNI/UA1YBZ0DQIQgEAwBBD3YIaSjkAAAhCoEUDcayxIQQACEAiGAOIezFDSEQhAAAI1Aoh7 jQUpCEAAAsEQQNyDGUo6AgEIQKBGAHGvsSAFAQhAIBgCiHswQ0lHIAABCNQIIO41FqQgAAEIBEMA cQ9mKOkIBCAAgRqB/wAoLQQNWSy3+QAAAABJRU5ErkJggg== --_005_D2726DD940B85johnmattssonericssoncom_-- From nobody Wed Nov 18 09:03:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317481A898F for ; Wed, 18 Nov 2015 09:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-NF37QS3p4y for ; Wed, 18 Nov 2015 09:03:49 -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 2F3CD1A8928 for ; Wed, 18 Nov 2015 09:03:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2CB56BE3E; Wed, 18 Nov 2015 17:03:47 +0000 (GMT) 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 YZ6iYpYpNUdp; Wed, 18 Nov 2015 17:03:47 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D792BE33; Wed, 18 Nov 2015 17:03:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447866226; bh=l9gKA6nG1+y+Q8Uv+X8A3sQvi8somr0oW8MHqXSyCKg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bUVZ6sfUqIrpADJKfvyrnJM0wL+g08XgO801pzDA65FbK+pZ54N1xIEMuSbGkydfH KYhcLdqSxFunNRSzSOJBkKyOzvAMGUIclZGaaYdl8BkajFbarm8xdVVIGodtj/wweZ pM/kHY/81sURxEURcl7NPGWrRF2uUXmfLnC+s8Us= To: Paul Hoffman References: <564C5FCC.8080107@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564CAF70.3030605@cs.tcd.ie> Date: Wed, 18 Nov 2015 17:03:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:03:51 -0000 On 18/11/15 16:48, Paul Hoffman wrote: > How can this WG be "short-lived" when you have the following in the > charter? My assumption (possibly wrong) was that the curdle wg would do the work on adding things and if, whilst doing that, they find stuff that can be deprecated, then they can choose to go do the work to deprecate stuff. But that the plan is to close when the new stuff is done. My intent fwiw was not that this wg hang around for ever figuring out what to deprecate next. Does that help? If so, figuring out how to say it better would be an improvement. (Any suggestions?) > > As the CURDLE working group will be handling changes to protocols and > registries some of which include what are now considered outdated > algorithm > options, the working group can also choose to propose deprecation of such > algorithms. Such deprecation needs to be done with care, ensuring that > interoperability and the needs of existing implementers and deployments are > properly considered. Where deprecation is practical, the working group is > encouraged to deprecate. > > Arguing about what is outdated always takes a long time. "It's still > good enough for the next five years." "No one ever changes their > software so we need to do this early." "We have people who need to use > this for another ten years and they understand the consequences." "We > can ignore this small set of users." "We cannot ignore this small set of > users." "We got rid of that algorithm in TLS and it didn't hurt." "Our > users are different than web browser users." "The charter says we must > do this 'with care' and you are being careless." "No, you're just being > stubborn." We would have that argument again yes. Maybe we'd get better at handling it if we do it in a more concentrated fashion? I'm not sure we would, but I figure it may be worth trying, esp as I'd bet that we do find things we'd want to deprecate. > Without that paragraph in the charter, I'm pretty sure consensus will be > easy. Do you mean consensus on the charter? (I think you do, just checking) S > > --Paul Hoffman > From nobody Wed Nov 18 09:24:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B8E1A8ADA for ; Wed, 18 Nov 2015 09:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 hsxgWCC4Dbxr for ; Wed, 18 Nov 2015 09:24:40 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0D61A8AC3 for ; Wed, 18 Nov 2015 09:24:39 -0800 (PST) Received: from BLUPR05CA0059.namprd05.prod.outlook.com (10.141.20.29) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 18 Nov 2015 17:24:37 +0000 Received: from BY2FFO11FD012.protection.gbl (207.46.163.244) by BLUPR05CA0059.outlook.office365.com (10.141.20.29) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Wed, 18 Nov 2015 17:24:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Wed, 18 Nov 2015 17:24:36 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Nov 2015 09:24:36 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAIHOZD02087; Wed, 18 Nov 2015 09:24:35 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id ACC4C1148F; Wed, 18 Nov 2015 09:24:34 -0800 (PST) To: Stephen Farrell In-Reply-To: <564C5FCC.8080107@cs.tcd.ie> References: <564C5FCC.8080107@cs.tcd.ie> Comments: In-reply-to: Stephen Farrell message dated "Wed, 18 Nov 2015 11:23:56 +0000." From: "Mark D. Baushke" Date: Wed, 18 Nov 2015 09:24:34 -0800 Message-ID: <89505.1447867474@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD012; 1:QBXBSYTs3DMUFzdOB+wWXTavVFgtR7FEJtPlG/2qNrsl3jbx7dxND5qpGSa6WMOeCfV5ZBvvMdIkFq1dZSzh67VGTHfa1t0gEmwE92tyMl30KzXyMdPFbz4VkF36XUI78b9GC/PX6VDjPZVXXtQUTMsz1rzFve9KVwOvBAfQYzzmzIxUyMjEr11fwAbbJKr2SHvnggnLvCh2Fz45LnOa5wkpJPJxbIbhebfB8etQgM3Go7iigwkW7cssSU+KgUF80TSiWGDX5akgP3eLLjNl+23xvgxpXYkNWXM6LbhbYhs5ya3rwvpgoON3/Y6hkp+Atp8USv7eUamDCxk9vmhbOxpHyR8LzwXVkbY+aRc6WqeqHTV7rIlurM+EVDDrDH/K X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(54094003)(199003)(189002)(164054003)(92566002)(81156007)(5001960100002)(5007970100001)(76506005)(97736004)(54356999)(189998001)(110136002)(53416004)(117636001)(105596002)(5001920100001)(106466001)(21840400001)(5003940100001)(6806005)(87936001)(50986999)(19580405001)(69596002)(19580395003)(76176999)(50466002)(48376002)(77096005)(2950100001)(15975445007)(586003)(47776003)(86362001)(5003600100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB059; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 2:ZPME2ANboMQTV6XOTp8bARG0h46oc6dzcK0EmmHu3A5cRrKtY0LKLBr3dACV6/7ldwpE7/b6JlZ1FkZj/kvOHIrKQ2pkFcvAnhtXACVZ8105xaTjiUzgUvv7G50VW4Nl/+dldVGwXrSU2qkGi45KpjeTHxk0ISL34OAQi6TeA9A=; 3:EYyAHHp9ARiJt8+hvB8v8qFjcpTUMaxGur2p1IfCt1H5it7mBiV2XAE/ofaJ1XefIQntgcMr/0byY7XhJrz2U1Jug3r+z9NCm3qh0QGe7egMzz6dMgOdGJ7s8BOAUScPgi9jTsTbg8x+PxOPCfzZGbfoYFcSdiAz/RQT7pm6u4rgIB5XVzhKJXXbGZmSbspzAY9ilqZNTVB4ErUV6QJSbiK8+YJWn6MN30v1vY1sEbk=; 25:8aSop6xTgIocQYwNDkj/cGVlzVBsaQa2J65fZLqFhQXaHjP8S8jNHNisRE25q29b9MPnba7rFHTkVnNgUf8yhn7vx3awFb0WNDKsnuHZk2Wm15EHw2ElIJy8WOzMkelyfOHZVpA+gi+XohTLG95ascmrVOUATBwVmehsSyhhZ1ooyMTh5H0j2UfEAmczVs5l09zI6TJyTuT2/w18tGyz6yMOxlRJquqdifR8nQSccHD83tfvnXNKPrmRMWmB/F/5a9GiatnF/+G1thxjyFOMrA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB059; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 20:IHRa+FRueXQxxSIdLizGWuy4wy4ezb0wQ90upbU21rVb3Pf9OTYQmrtfGqBOEfrPj9NDTrTqZ4VZeraUoVr6VHyTW0bXLqHNZMMwlqzlYWnzoMBXdi2jkUDaMEYFmsumR+EgEh+v+yeoziVLULW7RctuvOnIw0ITAMAiGU2md/1rtpeMnGlirg5OOR7VFmBWdliWVupkn5xs48/K865AMz/7V9rh6Fmkik4fyiAL9of/lEMuADdLFIcSI8PqbTP6f9WulcHkFgFV2hKk+bJ5iRBoD0PjqzNBKCUCfaQXuGzwlt+1v2iXf4UIUGSW9TSI8MMnOCrAAd3NQfSnTl4YTDNaM96pwN1Mv2nBmRwniz5KpgrADfLzbRlLV+n8TyFVfz8gMvBR4b9gSjxxFlGQTeQBMI1u6phZbToUNa4tMIvv2qC0/A99Nm7pw0Bn84lgATW3DSjzfykhkuTrnTQFtDa6qaR/zkuEeMx/TFvr2aepyrFp8ZR/VYZDjgAtt5LM; 4:QhZpB3YC17F7B5cQv+1vnz7Pi2y69EGM1VJzWZ/xv16oTwXtOQDqcWPjdJtDJeSYn0J0WJVbgoc7nP/RW2Ux0Qc8d6vB4ZWTQVwupwnKP0WCyE5W962Y4JyXcqROK3jBwO+BRw5uqHrqEhhmMfm2eiIsyzd11I0y5sJgOdO89uzVSYeyWn9R2EMrIDmEhyjBJIQQpz/TRxLCO2zwUXDKmzXXHw9DxojU2ZwZmXoN3dMRgvu94lXJNvypwfUX/TaLVT2/wDN6avC62PNtgH7u1LzNKm0EirIATytErEzuNOTYMenQXeje4j2x5ilMHvGnBPDIpWcg9iarse29RkFXZjhfm4jSp5o5+YqO+3HBOkfVWM1pzMP93EXyswHh8JzE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(32856632585715); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BN1PR05MB059; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB059; X-Forefront-PRVS: 0764C4A8CD X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB059; 23:Msr+o6Kk3USbWvsvdGKbHMjpe3TDyj/7CU0+fNB2Ty?= =?us-ascii?Q?UixX9eAx+hY5x2EdV/YGT9H7sBKCYWl/qqzV51/NO49e1JLanB4Vul71Ga1S?= =?us-ascii?Q?qhFc3g7fCUNLw82IxSI99RCWANuvYdkhmwl+i2q8bQjJ3frd1tkh3HuuOM4B?= =?us-ascii?Q?M4MRPgv2Pn2ss50njNE1WAgt3aTuoJcW6dSfStnAywcv1mV5Wqb4+te/bDvC?= =?us-ascii?Q?RICrOBlp657Qwvzjz2PFk+lMh86Q/wUDIfLlUlMMeykNtAcM/tx0y6weaZ3I?= =?us-ascii?Q?rM5/60GNaWW0UyI21R3InLRLul8gA6dY52jZMISQUDRHetOmRh/G5nEe3vT6?= =?us-ascii?Q?N0ETDjl/mT7qoXffa/vuvP4yHad6UxRf9qgrpj2MHQi4lPw1ANw3H6A7/Mtm?= =?us-ascii?Q?0FO9GeajOmXWHra3WtqB/MCibuzcrFOcIw1Yy9dibkzr5I9KzXF2SshQko3I?= =?us-ascii?Q?xDauenfT9oMWcNrJniD5l1YVaXr9uBqJL9ycFteaO9Ph7A5YcQ3NFHY0hHMz?= =?us-ascii?Q?QHx/m7TO79oB4mNd33m8UwyBp3DGOStVm/ar6Y+D0+yo4pSJdBUjHcOduvc9?= =?us-ascii?Q?CcpAWcNF0VTpJMsiZMaHnlvwJGls3wQdXSD+r3tNsK4LwmOgmDdYcIKOM/v6?= =?us-ascii?Q?zX8kSB/euyo1apOqTlgn+dFzjJVJsrjvW/cUDCbPmljtHa2MFqs99rqqeC9X?= =?us-ascii?Q?LYtwWBNsSQGmKiVkWyMliljTTouaXIq4jivfsoMtJ+DdLdUIo2QtHeX3Yn3X?= =?us-ascii?Q?7gk0dSExZgp78F+0JjiWKdyHqL2xtkk/WnBhD742t3UHg8MXiGweFew4sSOc?= =?us-ascii?Q?Zpqb5HigbQXvEwqc4Q09qrlR6f8IyCMxUROqOMkIpBfU3hdn8cLPUWh9Qypu?= =?us-ascii?Q?HCflIRuLkUjTg9SWXJSSa8YW7fzVykKWRkuRl3Wah9cIqLXVU50E0MJlpt0y?= =?us-ascii?Q?JfLbeS+X/gA9p5snGDsN6WUk3JCCOzokmjlZzlw6xiDiFEKHxssK6DEY8ZQJ?= =?us-ascii?Q?1gYe+jxuGSDuVLkYKaqSqrMsvF+uWxgGVeDBeYNkQ8wWbds08pD1wmziktcw?= =?us-ascii?Q?EkQ3wsJiKeIHxCroHI1tvqN63a?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB059; 5:AeSj89Y0K2FDakNgmZDue7qQvB6HzP8vTi03XsJ0nYPMS8d/Gp/wxqNIqQL7qwt3BcqQLaNZ949qtleO34Aw1KIg7IQLUzxFN1vQFML45hC7GP8YLVC2Ygjtf1N+0CWP/qvb3v4ShxD+35Es733qHA==; 24:AXpczq7PrDQ/EUAT59ovvTNyOZmqq9Xrre+5XawIYTLuh4XslJbFf9rysvhmEI0Br9NIZdrZmx8GJXGU0fvkUAn0dVzFvAFyY5C/VQjGuTk=; 20:12iNQr0Vy3cUu8g7qjMnPNfqdHOwhM4XEvPIC9D2d9kplCgyaIbn98weymNdyH3SyGisklYf0hvIQWO2lo2sbQ== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Nov 2015 17:24:36.8621 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB059 Archived-At: Cc: ietf-ssh@NetBSD.org, "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:24:43 -0000 Hi Stephen, Stephen Farrell writes: > If you have changes to charter text to suggest please do so, > preferably in OLD/NEW form. The charter seems reasonable to me. > If there's not enough interest or if there're sound objections then > we can abandon the idea and fall back to processing this stuff more > slowly and more ad-hoc as AD sponsored drafts. (The main point of > curdle is to be more organised and hopefully quicker at this.) > > Thanks, > S. > > [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ > > (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and > Sean Turner for help with the text. The fault however is mine, > if it's bad text or a dumb idea:-) > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag I wonder if RFC 5647 which is an information RFC for "AES Galois Counter Mode for the Secure Shell Transport Layer Protocol" could be cleaned up to address the problems of the key exchange as expressed by the OpenSSH team and made into a standard track document? To quote the objection from the OpenSSH PROTOCOL document: | 1.6 transport: AES-GCM | | OpenSSH supports the AES-GCM algorithm as specified in RFC 5647. | Because of problems with the specification of the key exchange | the behaviour of OpenSSH differs from the RFC as follows: | | AES-GCM is only negotiated as the cipher algorithms | "aes128-gcm@openssh.com" or "aes256-gcm@openssh.com" and never as | an MAC algorithm. Additionally, if AES-GCM is selected as the cipher | the exchanged MAC algorithms are ignored and there doesn't have to be | a matching MAC. Given that current implementatons of this informational RFC are using AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track Cipher algorithms use lowercase with '-' as word separators, I would suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and that they should NOT be added to the MAC Algorithms Names in IANA. This same objection would arise to any AEAD Cipher, so I think it might be well to do something similar for SSH for standardize "chacha20-poly1305" for Secure Shell again as a Cipher name only with the MAC Algorithm Name ignored. Thank you, -- Mark From nobody Wed Nov 18 09:29:20 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AEB1A8AE0 for ; Wed, 18 Nov 2015 09:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmrN49lHF2sH for ; Wed, 18 Nov 2015 09:29:17 -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 D85621A8ADF for ; Wed, 18 Nov 2015 09:29:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EEC94BE4D; Wed, 18 Nov 2015 17:29:14 +0000 (GMT) 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 JhDlTAWkKjno; Wed, 18 Nov 2015 17:29:14 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 03252BE47; Wed, 18 Nov 2015 17:29:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447867754; bh=qvrHMSayQNsJZ0lZ3TVfazWilVT3d1tZnhj2cCwrtNQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=GJGBdwpAAAYciM+MNeZhY38EyRSK9mfrzc6mKMqFdJ1strqt/Ii49/JcBO4rl22MS XPHCicVZp3q6uyDXiOARHCLpqBA8dPNIAczeDMPV/T0mLpDaPpzvkd5oXWW8UNzebj lgyW4vkCLP+AfLRBkPAh567PstGJIgJEn8ITd/po= To: John Mattsson , "saag@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 Message-ID: <564CB568.2060901@cs.tcd.ie> Date: Wed, 18 Nov 2015 17:29:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:29:19 -0000 Hiya, On 18/11/15 17:03, John Mattsson wrote: > Hi, > > Excellent! Well needed and a good written charter. > > I agree with Eliots earlier comments, and I have one additional > suggestion. > > The current charter only allows the working group to introduce new > mechanisms (which would then be MAY support) or deprecate old > algorithms (which would then be MUST NOT support?). I think the group > should also have the possibility to create profiles similar to > RFC7321, RFC4307bis, and TLS 1.3 Section 8 (i.e MUST, SHOULD, MAY, > SHOULD NOT, MUST NOT support…). If the WG had consensus to e.g. propose " as a MUST for SSH" for some reasonable then I think that would be fine and within the charter scope. Do we need to add text to say that? If so, what? > I have recently driven a profile > update of all 3GPP usage of IETF Security Protocols as well as an > internal update of Ericsson's usage of security mechanisms. > Implementation Requirements and Usage Guidance for at least SSH and > PKIX would be very useful to have. > > Some editorials: “and JSON” -> "and JOSE" “AES-CCM[4]” -> “AES-CCM Ta, S. > [4]" > > Cheers, John > > On 11/18/15 12:23 PM, Stephen Farrell wrote: >> Hiya, >> >> Following on from the earlier discussion about adding curves etc. a >> few folks (*) helped Kathleen and I craft an initial cut at charter >> text. [1] >> >> I think we have people (well, mostly Simon:-) to do the editing >> work for this. >> >> If you'd be willing to be a chair, please send an offlist mail to >> Kathleen and I. >> >> If you think this is useful and would review documents please >> respond to this mail saying so. I'd like to see that we have enough >> folks interested to make this work. >> >> If you have changes to charter text to suggest please do so, >> preferably in OLD/NEW form. >> >> If you think this is a bad idea, I'm sure you'll not be shy in >> saying so too:-) >> >> If there's not enough interest or if there're sound objections >> then we can abandon the idea and fall back to processing this stuff >> more slowly and more ad-hoc as AD sponsored drafts. (The main point >> of curdle is to be more organised and hopefully quicker at this.) >> >> Thanks, S. >> >> [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ >> >> (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and Sean >> Turner for help with the text. The fault however is mine, if it's >> bad text or a dumb idea:-) >> >> _______________________________________________ saag mailing list >> saag@ietf.org https://www.ietf.org/mailman/listinfo/saag >> > > > JOHN MATTSSON MSc Engineering Physics, MSc Business Administration > and Economics Ericsson IETF Security Coordinator Senior Researcher, > Security > > Ericsson AB Ericsson Research Färögatan 6 SE-164 80 Stockholm, > Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 > john.mattsson@ericsson.com > www.ericsson.com > > > [http://www.ericsson.com/] > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out > atwww.ericsson.com/email_disclaimer > > > > > _______________________________________________ saag mailing list > saag@ietf.org https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Nov 18 09:33:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5914C1A7113 for ; Wed, 18 Nov 2015 08:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=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 n4jXrBQfQ2R6 for ; Wed, 18 Nov 2015 08:48:08 -0800 (PST) Received: from hoffman.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 0F5561A710D for ; Wed, 18 Nov 2015 08:48:08 -0800 (PST) Received: from [10.32.60.56] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tAIGlx8n097371 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2015 09:48:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.56] From: "Paul Hoffman" To: "Stephen Farrell" Date: Wed, 18 Nov 2015 08:48:05 -0800 Message-ID: In-Reply-To: <564C5FCC.8080107@cs.tcd.ie> References: <564C5FCC.8080107@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: X-Mailman-Approved-At: Wed, 18 Nov 2015 09:33:51 -0800 Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 16:48:13 -0000 How can this WG be "short-lived" when you have the following in the charter? As the CURDLE working group will be handling changes to protocols and registries some of which include what are now considered outdated algorithm options, the working group can also choose to propose deprecation of such algorithms. Such deprecation needs to be done with care, ensuring that interoperability and the needs of existing implementers and deployments are properly considered. Where deprecation is practical, the working group is encouraged to deprecate. Arguing about what is outdated always takes a long time. "It's still good enough for the next five years." "No one ever changes their software so we need to do this early." "We have people who need to use this for another ten years and they understand the consequences." "We can ignore this small set of users." "We cannot ignore this small set of users." "We got rid of that algorithm in TLS and it didn't hurt." "Our users are different than web browser users." "The charter says we must do this 'with care' and you are being careless." "No, you're just being stubborn." Without that paragraph in the charter, I'm pretty sure consensus will be easy. --Paul Hoffman From nobody Wed Nov 18 09:38:19 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3FB1A00C3 for ; Wed, 18 Nov 2015 09:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SMvVcJyCGTx for ; Wed, 18 Nov 2015 09:38:17 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B2E1A00BC for ; Wed, 18 Nov 2015 09:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2043; q=dns/txt; s=iport; t=1447868296; x=1449077896; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=/y9fUtlZZHHtLHSqFdRoOhvxl1Gx5c0uGC5jvxdFJ7I=; b=PlKhwm6Y0/UJDio/UNBdTwphOSjbRjnwowl/kN36mhbo3ueVAIvPzppa GX7CzncCAPKp142jIyzl8gH36Glvz4TSL0nCTcKda8JXUI9XhXYD2tSIk VWxjExczC5Qj0RZ7ErIqRpVOrHNVs/YvxZZyr1txebvCF3Bew4R1YaTFG 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2BADztUxW/xbLJq1exUaDPYJSAoIcA?= =?us-ascii?q?QEBAQEBgQuENQEBBCNVARALGAkWCwICCQMCAQIBRQYBDAgBAYgqrwuQRgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQERCYtSh3WBRAEElkqCV4FgiHSJHZMoY4QFPYVAAQEB?= X-IronPort-AV: E=Sophos;i="5.20,313,1444694400"; d="asc'?scan'208";a="606391109" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2015 17:38:13 +0000 Received: from [10.61.220.78] ([10.61.220.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAIHcCs4031410; Wed, 18 Nov 2015 17:38:12 GMT To: Stephen Farrell , Paul Hoffman References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> From: Eliot Lear Message-ID: <564CB783.8070901@cisco.com> Date: Wed, 18 Nov 2015 18:38:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CAF70.3030605@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtAsE1j67rwh5toFRd2ajR64w3sixrUPt" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:38:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vtAsE1j67rwh5toFRd2ajR64w3sixrUPt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, Just one further thought... On 11/18/15 6:03 PM, Stephen Farrell wrote: > > On 18/11/15 16:48, Paul Hoffman wrote: >> How can this WG be "short-lived" when you have the following in the >> charter? > My assumption (possibly wrong) was that the curdle wg would do > the work on adding things and if, whilst doing that, they find > stuff that can be deprecated, then they can choose to go do the > work to deprecate stuff. But that the plan is to close when the > new stuff is done. > > My intent fwiw was not that this wg hang around for ever figuring > out what to deprecate next. > > Does that help? If so, figuring out how to say it better would > be an improvement. (Any suggestions?) Thinking out loud... One possible way to think about the trajectory of this group is that it could transition from a WG to some sort of directorate so that when it deems the time is right it can propose next steps, either piecemeal or wholesale as the circumstances warrant. Building up and maintaining that sort of capability for the IETF IMHO would be a good thing. Eliot --vtAsE1j67rwh5toFRd2ajR64w3sixrUPt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWTLeEAAoJEIe2a0bZ0noz6OgH/0bGuOQbH/2jIlIg0RRbIEy8 a+q9xaaRvPFcx1xNAeEGFQ9mh7FziE7lWXyJJ3GeCLOY3OikHEOOBASYxNHCerUk HX+7vio8OjxLjGVduhHnEeKgMDz2WmC1+8WOG/ZtF6eKZuaF4WwG6NDH4YRnoyiL XT3oN/enufu7V80cFezEkWi7UWgyNqcEGxNEYhJmqP8Oueyo8OOhdMlzEHCVe4D/ IZaM2vdzdJN196eGTWGj6F0JqHfWO2p2kma5SkRPGbaJHmWDQnhQ9oQncoYKL2Ku KtMMcHm2dO4A2/TKiy4ozxuNAfcdPDqL6cE+/Qw6fAXJiOdY54lEJ9+Er7aNltA= =Tt6H -----END PGP SIGNATURE----- --vtAsE1j67rwh5toFRd2ajR64w3sixrUPt-- From nobody Wed Nov 18 09:42:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A401A010C for ; Wed, 18 Nov 2015 09:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSfg7m-e3snb for ; Wed, 18 Nov 2015 09:42:03 -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 9D64B1A0108 for ; Wed, 18 Nov 2015 09:42:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 25D6ABE4D; Wed, 18 Nov 2015 17:42:02 +0000 (GMT) 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 DnLMUU7TOPAR; Wed, 18 Nov 2015 17:42:02 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 470E3BE47; Wed, 18 Nov 2015 17:42:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447868521; bh=tkrI0OLb3YDlzwk8dkTky6exNK33KVdAyTVRwjkiIyk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YUrpunN1uFfZM/AQSMz4DTvQWoQyljbpdea4OGPXyrE9sT1+g1SvlZRi2cBO93omb uZ3BO4mB68LAOfmSzbsDNteYxlyLoRapqrYQOpvfPKiaBCX2GPP85As92iEaXLBahy tuj7mh1suKMfPB5D+xUvBdriAYYDY0Q3uEjlfUYM= To: Eliot Lear , Paul Hoffman References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <564CB783.8070901@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564CB865.7090705@cs.tcd.ie> Date: Wed, 18 Nov 2015 17:41:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CB783.8070901@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="S7fJnX2UdnATRKroAWQXEOHtEOo7llSCM" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:42:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S7fJnX2UdnATRKroAWQXEOHtEOo7llSCM Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 18/11/15 17:38, Eliot Lear wrote: > Hi Stephen, >=20 > Just one further thought... >=20 > On 11/18/15 6:03 PM, Stephen Farrell wrote: >> >> On 18/11/15 16:48, Paul Hoffman wrote: >>> How can this WG be "short-lived" when you have the following in the >>> charter? >> My assumption (possibly wrong) was that the curdle wg would do >> the work on adding things and if, whilst doing that, they find >> stuff that can be deprecated, then they can choose to go do the >> work to deprecate stuff. But that the plan is to close when the >> new stuff is done. >> >> My intent fwiw was not that this wg hang around for ever figuring >> out what to deprecate next. >> >> Does that help? If so, figuring out how to say it better would >> be an improvement. (Any suggestions?) >=20 > Thinking out loud... >=20 > One possible way to think about the trajectory of this group is that it= > could transition from a WG to some sort of directorate so that when it > deems the time is right it can propose next steps, either piecemeal or > wholesale as the circumstances warrant. Building up and maintaining > that sort of capability for the IETF IMHO would be a good thing. I think that's a fair point to consider after the wg is up and running and has demonstrated success for a bit so maybe getting the curves etc additions done first and then considering this as a possible re-charter would be reasonable. One thing to consider then would be whether or not folks would have sufficient energy for such ongoing efforts. For now though, I think we do seem to have folks willing to do the initial work, so starting with that seems like a good place to start. Cheers, S. >=20 > Eliot >=20 >=20 --S7fJnX2UdnATRKroAWQXEOHtEOo7llSCM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWTLhnAAoJEC88hzaAX42iLzgH/i8beRMjTlskmgResKzvzZ/p xf2qe2Erua9RcomCAgvUUBJk/sXoUTOxk+jnFknG0PQTvYpqrhpP4HgDsll/2mrx 494taDaBA/ekGqygaFz4tHOp0/6UQ/EQRlUutC4/29PfIKcjQtBOuj1x4DGHtk9s J+GIJgtJppSkdIj3I8obKDJ2tDB004LTOapYVTvNcZrzZJJaGrpSzg2M9rUwnuYS sL2SvhaS4ZcggdDWJlYuxudv5JLMLcO1nAxSpZrbl3AWLKnL8Yvq4uJsZZkAlTt4 Je9MqOyPH8WW7AD++kbDDKHPbYr84mL5YC7D3EBD5Zubudi9F96p4D4mUj5lsOo= =bqhL -----END PGP SIGNATURE----- --S7fJnX2UdnATRKroAWQXEOHtEOo7llSCM-- From nobody Wed Nov 18 09:50:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1C1A01A8 for ; Wed, 18 Nov 2015 09:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FU_ENDS_2_WRDS=0.255, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo-gw4KrgOaU for ; Wed, 18 Nov 2015 09:50:23 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB0C1A0203 for ; Wed, 18 Nov 2015 09:50:22 -0800 (PST) X-AuditID: c1b4fb30-f79626d000006adf-b8-564cba5c9133 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.23.27359.C5ABC465; Wed, 18 Nov 2015 18:50:20 +0100 (CET) Received: from ESESSMB310.ericsson.se ([169.254.10.15]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 18:50:20 +0100 From: John Mattsson To: Stephen Farrell , "saag@ietf.org" Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIiL+yxwHZkFPGkGCMx9vxuLjV56h+D0AgAAWqoA= Date: Wed, 18 Nov 2015 17:50:20 +0000 Message-ID: References: <564CB568.2060901@cs.tcd.ie> In-Reply-To: <564CB568.2060901@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.150] Content-Type: multipart/mixed; boundary="_002_D27276BA40BD8johnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsUyM2J7oG7MLp8wg+eTrCym9HcyWUzfe43d gcljbfdVNo8lS34yBTBFcdmkpOZklqUW6dslcGV8PHSYqWBmSMWFPztYGhhvBnYxcnJICJhI bL86jxnCFpO4cG89WxcjF4eQwGFGiZ5J91ghnCWMEme3b2UEqWITMJCYu6eBDcQWEQiS+D/j ESuILQwU37h0GxNE3FDi4K79zBC2lcSZSwfAelkEVCWOPnrBDmLzCphLfF3bCGYLCYRJbNx4 B2wmp4CmxPvl38FmMgJd9P3UGrCZzALiEreezGeCuFRE4uHF02wQtqjEy8f/gOo5OEQF9CT2 LJeECCtJrNh+iREkzAw0fn97HMRWQYmTM5+wTGAUnYVk6CyEqllIqiDCmhLrd+lDVFtLfN0z mw3CVpSY0v2QHcI2kTjz7BkLhK0sseTtAsZZwHBjFljNKPH240pmmOYjS86wI2tewMi9ilG0 OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwlg9u+W2wg/Hlc8dDjAIcjEo8vAUbvcOEWBPLiitz DzGqAM15tGH1BUYplrz8vFQlEV7tap8wId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzNTA9ChQTS E0tSs1NTC1KLYLJMHJxSDYwBanfLxXrsDt2XeK0h43yz6q+qRfv/lexxcwQCVs+6HMPy++mV T8JWTm+bS5qP7BTgKqit/9h8zPDLPPmSO1wL9M9uEmRzUfPquJ0ttKsoj6tnL6vAZYljL5es u6QlX/39rVsF4/P6GiH1dcn+ugYsT/ncntQtOb3V702Z6RbVr0t8tp8U81JiKc5INNRiLipO BAD/Zgnr7QIAAA== Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:50:25 -0000 --_002_D27276BA40BD8johnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-ID: <8A5EA8B0A4D36742B29742EA2FF6C5CD@ericsson.com> Content-Transfer-Encoding: base64 DQoNCk9uIDE4LzExLzE1IDE4OjI5LCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT4gd3JvdGU6DQoNCj4NCj5IaXlhLA0KPg0KPk9uIDE4LzExLzE1IDE3OjAzLCBK b2huIE1hdHRzc29uIHdyb3RlOg0KPj4gSGksDQo+PiANCj4+IEV4Y2VsbGVudCEgV2VsbCBuZWVk ZWQgYW5kIGEgZ29vZCB3cml0dGVuIGNoYXJ0ZXIuDQo+PiANCj4+IEkgYWdyZWUgd2l0aCBFbGlv dHMgZWFybGllciBjb21tZW50cywgYW5kIEkgaGF2ZSBvbmUgYWRkaXRpb25hbA0KPj4gc3VnZ2Vz dGlvbi4NCj4+IA0KPj4gVGhlIGN1cnJlbnQgY2hhcnRlciBvbmx5IGFsbG93cyB0aGUgd29ya2lu ZyBncm91cCB0byBpbnRyb2R1Y2UgbmV3DQo+PiBtZWNoYW5pc21zICh3aGljaCB3b3VsZCB0aGVu IGJlIE1BWSBzdXBwb3J0KSBvciBkZXByZWNhdGUgb2xkDQo+PiBhbGdvcml0aG1zICh3aGljaCB3 b3VsZCB0aGVuIGJlIE1VU1QgTk9UIHN1cHBvcnQ/KS4gSSB0aGluayB0aGUgZ3JvdXANCj4+IHNo b3VsZCBhbHNvIGhhdmUgdGhlIHBvc3NpYmlsaXR5IHRvIGNyZWF0ZSBwcm9maWxlcyBzaW1pbGFy IHRvDQo+PiBSRkM3MzIxLCBSRkM0MzA3YmlzLCBhbmQgVExTIDEuMyBTZWN0aW9uIDggKGkuZSBN VVNULCBTSE9VTEQsIE1BWSwNCj4+IFNIT1VMRCBOT1QsIE1VU1QgTk9UIHN1cHBvcnTigKYpLg0K Pg0KPklmIHRoZSBXRyBoYWQgY29uc2Vuc3VzIHRvIGUuZy4gcHJvcG9zZSAiPGZvbz4gYXMgYSBN VVNUIGZvciBTU0giDQo+Zm9yIHNvbWUgcmVhc29uYWJsZSA8Zm9vPiB0aGVuIEkgdGhpbmsgdGhh dCB3b3VsZCBiZSBmaW5lIGFuZA0KPndpdGhpbiB0aGUgY2hhcnRlciBzY29wZS4gRG8gd2UgbmVl ZCB0byBhZGQgdGV4dCB0byBzYXkgdGhhdD8gSWYNCj5zbywgd2hhdD8NCg0KSSB0aGluayBpdCB3 b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgdGhhdCwgc3VnZ2VzdGlvbjoNCg0KT0xEOg0KVGhlICBD VVJETEUgd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQgdG8gYWRkIGEgc21hbGwgc2V0IG9mIGNy eXB0b2dyYXBoaWMNCm1lY2hhbmlzbXMgdG8gc29tZSBJRVRGIHByb3RvY29scywgYW5kIHRvIGRl cHJlY2F0ZSBvbGQgYWxnb3JpdGhtcyB3aGVyZQ0KdGhlcmUNCmlzIElFVEYgY29uc2Vuc3VzIHRv IGRvIHNvLg0KDQoNCk5FVzoNClRoZSBDVVJETEUgd29ya2luZyBncm91cCBpcyBjaGFydGVyZWQg dG8gYWRkIGEgc21hbGwgc2V0IG9mIGNyeXB0b2dyYXBoaWMNCm1lY2hhbmlzbXMgdG8gc29tZSBJ RVRGIHByb3RvY29scywgYW5kIHRvIG1ha2UgaW1wbGVtZW50YXRpb24gcmVxdWlyZW1lbnRzDQpp bmNsdWRpbmcNCmRlcHJlY2F0aW9uIG9mIG9sZCBhbGdvcml0aG1zIHdoZXJlIHRoZXJlIGlzIElF VEYgY29uc2Vuc3VzIHRvIGRvIHNvLg0KDQoNCg0KPg0KPj4gSSBoYXZlIHJlY2VudGx5IGRyaXZl biBhIHByb2ZpbGUNCj4+IHVwZGF0ZSBvZiBhbGwgM0dQUCB1c2FnZSBvZiBJRVRGIFNlY3VyaXR5 IFByb3RvY29scyBhcyB3ZWxsIGFzIGFuDQo+PiBpbnRlcm5hbCB1cGRhdGUgb2YgRXJpY3Nzb24n cyB1c2FnZSBvZiBzZWN1cml0eSBtZWNoYW5pc21zLg0KPj4gSW1wbGVtZW50YXRpb24gUmVxdWly ZW1lbnRzIGFuZCBVc2FnZSBHdWlkYW5jZSBmb3IgYXQgbGVhc3QgU1NIIGFuZA0KPj4gUEtJWCB3 b3VsZCBiZSB2ZXJ5IHVzZWZ1bCB0byBoYXZlLg0KPj4gDQo+PiBTb21lIGVkaXRvcmlhbHM6IOKA nGFuZCBKU09O4oCdIC0+ICJhbmQgSk9TRSIg4oCcQUVTLUNDTVs0XeKAnSAtPiDigJxBRVMtQ0NN DQo+DQo+VGEsDQo+Uy4NCj4NCj4NCj4+IFs0XSINCj4+IA0KPj4gQ2hlZXJzLCBKb2huDQo+PiAN Cj4+IE9uIDExLzE4LzE1IDEyOjIzIFBNLCBTdGVwaGVuIEZhcnJlbGwgd3JvdGU6DQo+Pj4gSGl5 YSwNCj4+PiANCj4+PiBGb2xsb3dpbmcgb24gZnJvbSB0aGUgZWFybGllciBkaXNjdXNzaW9uIGFi b3V0IGFkZGluZyBjdXJ2ZXMgZXRjLiBhDQo+Pj4gZmV3IGZvbGtzICgqKSBoZWxwZWQgS2F0aGxl ZW4gYW5kIEkgY3JhZnQgYW4gaW5pdGlhbCBjdXQgYXQgY2hhcnRlcg0KPj4+IHRleHQuIFsxXQ0K Pj4+IA0KPj4+IEkgdGhpbmsgd2UgaGF2ZSBwZW9wbGUgKHdlbGwsIG1vc3RseSBTaW1vbjotKSB0 byBkbyB0aGUgZWRpdGluZw0KPj4+IHdvcmsgZm9yIHRoaXMuDQo+Pj4gDQo+Pj4gSWYgeW91J2Qg YmUgd2lsbGluZyB0byBiZSBhIGNoYWlyLCBwbGVhc2Ugc2VuZCBhbiBvZmZsaXN0IG1haWwgdG8N Cj4+PiBLYXRobGVlbiBhbmQgSS4NCj4+PiANCj4+PiBJZiB5b3UgdGhpbmsgdGhpcyBpcyB1c2Vm dWwgYW5kIHdvdWxkIHJldmlldyBkb2N1bWVudHMgcGxlYXNlDQo+Pj4gcmVzcG9uZCB0byB0aGlz IG1haWwgc2F5aW5nIHNvLiBJJ2QgbGlrZSB0byBzZWUgdGhhdCB3ZSBoYXZlIGVub3VnaA0KPj4+ IGZvbGtzIGludGVyZXN0ZWQgdG8gbWFrZSB0aGlzIHdvcmsuDQo+Pj4gDQo+Pj4gSWYgeW91IGhh dmUgY2hhbmdlcyB0byBjaGFydGVyIHRleHQgdG8gc3VnZ2VzdCBwbGVhc2UgZG8gc28sDQo+Pj4g cHJlZmVyYWJseSBpbiBPTEQvTkVXIGZvcm0uDQo+Pj4gDQo+Pj4gSWYgeW91IHRoaW5rIHRoaXMg aXMgYSBiYWQgaWRlYSwgSSdtIHN1cmUgeW91J2xsIG5vdCBiZSBzaHkgaW4NCj4+PiBzYXlpbmcg c28gdG9vOi0pDQo+Pj4gDQo+Pj4gSWYgdGhlcmUncyBub3QgZW5vdWdoIGludGVyZXN0IG9yIGlm IHRoZXJlJ3JlIHNvdW5kIG9iamVjdGlvbnMNCj4+PiB0aGVuIHdlIGNhbiBhYmFuZG9uIHRoZSBp ZGVhIGFuZCBmYWxsIGJhY2sgdG8gcHJvY2Vzc2luZyB0aGlzIHN0dWZmDQo+Pj4gbW9yZSBzbG93 bHkgYW5kIG1vcmUgYWQtaG9jIGFzIEFEIHNwb25zb3JlZCBkcmFmdHMuIChUaGUgbWFpbiBwb2lu dA0KPj4+IG9mIGN1cmRsZSBpcyB0byBiZSBtb3JlIG9yZ2FuaXNlZCBhbmQgaG9wZWZ1bGx5IHF1 aWNrZXIgYXQgdGhpcy4pDQo+Pj4gDQo+Pj4gVGhhbmtzLCBTLg0KPj4+IA0KPj4+IFsxXSBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtY3VyZGxlLw0KPj4+IA0K Pj4+ICgqKSBUaGFua3MgdG8gU2ltb24gSm9zZWZzc29uLCBZb2F2IE5pciwgUnVzcyBIb3VzbGV5 IGFuZCBTZWFuDQo+Pj4gVHVybmVyIGZvciBoZWxwIHdpdGggdGhlIHRleHQuIFRoZSBmYXVsdCBo b3dldmVyIGlzIG1pbmUsIGlmIGl0J3MNCj4+PiBiYWQgdGV4dCBvciBhIGR1bWIgaWRlYTotKQ0K Pj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f IHNhYWcgbWFpbGluZyBsaXN0DQo+Pj4gc2FhZ0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NhYWcNCj4+PiANCj4+IA0KPj4gDQo+PiBKT0hOIE1BVFRTU09O IE1TYyBFbmdpbmVlcmluZyBQaHlzaWNzLCBNU2MgQnVzaW5lc3MgQWRtaW5pc3RyYXRpb24NCj4+ IGFuZCBFY29ub21pY3MgRXJpY3Nzb24gSUVURiBTZWN1cml0eSBDb29yZGluYXRvciBTZW5pb3Ig UmVzZWFyY2hlciwNCj4+IFNlY3VyaXR5DQo+PiANCj4+IEVyaWNzc29uIEFCIEVyaWNzc29uIFJl c2VhcmNoIEbDpHLDtmdhdGFuIDYgU0UtMTY0IDgwIFN0b2NraG9sbSwNCj4+IFN3ZWRlbiBQaG9u ZSArNDYgMTAgNzEgNDMgNTAxIFNNUy9NTVMgKzQ2IDc2IDExIDUzIDUwMQ0KPj4gam9obi5tYXR0 c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPg0KPj4g d3d3LmVyaWNzc29uLmNvbTxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS8+DQo+PiANCj4+IA0KPj4g W2h0dHA6Ly93d3cuZXJpY3Nzb24uY29tL108aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vPg0KPj4g DQo+PiBUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5k IHJlY2VpdmUgZW1haWwgb24NCj4+IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dA0KPj4g DQo+PmF0d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93d3cuZXJpY3Nz b24uY29tL2VtYWlsX2Rpc2NsYWkNCj4+bWVyPg0KPj4NCj4+IA0KPj4gDQo+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHNhYWcgbWFpbGluZyBs aXN0DQo+PiBzYWFnQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FhZw0KPj4gDQoNCg== --_002_D27276BA40BD8johnmattssonericssoncom_ Content-Type: application/xml; name="default[1].xml" Content-Description: default[1].xml Content-Disposition: attachment; filename="default[1].xml"; size=3222; creation-date="Wed, 18 Nov 2015 17:50:20 GMT"; modification-date="Wed, 18 Nov 2015 17:50:20 GMT" Content-ID: <154A1BE4F4337C449F800C7CA845319F@ericsson.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_002_D27276BA40BD8johnmattssonericssoncom_-- From nobody Wed Nov 18 09:55:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618061A0358 for ; Wed, 18 Nov 2015 09:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.031 X-Spam-Level: X-Spam-Status: No, score=-4.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FU_ENDS_2_WRDS=0.255, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKra7H6Vf7_c for ; Wed, 18 Nov 2015 09:54:56 -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 88E391A034C for ; Wed, 18 Nov 2015 09:54:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9E988BE4D; Wed, 18 Nov 2015 17:54:54 +0000 (GMT) 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 MHp-ydSmIEu6; Wed, 18 Nov 2015 17:54:54 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A98F5BE47; Wed, 18 Nov 2015 17:54:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447869294; bh=cdGjDMD7S0P0pGE2Vj4IUTcxXJVJyC6VW8j+agkPLl0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eQxj3jWvsUGRim2uH/WgIkauV3kKhRB1bLFgPMQBoUpyYxL2LhLdo9rIzjfNuiWBv iQx9Boxu6AZBGIyMT3TvsTWakXdbTOim0pxxIvXKOKOyWwUszUcl4iSa/lAYxk4eax OrS3Po8nN7xAXjgnqk1lrOf3LRmsd4ImkXzrttFM= To: John Mattsson , "saag@ietf.org" References: <564CB568.2060901@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564CBB6C.2080406@cs.tcd.ie> Date: Wed, 18 Nov 2015 17:54:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 17:54:59 -0000 Hiya, On 18/11/15 17:50, John Mattsson wrote: > > > On 18/11/15 18:29, "Stephen Farrell" wrote: > >> >> Hiya, >> >> On 18/11/15 17:03, John Mattsson wrote: >>> Hi, >>> >>> Excellent! Well needed and a good written charter. >>> >>> I agree with Eliots earlier comments, and I have one additional >>> suggestion. >>> >>> The current charter only allows the working group to introduce new >>> mechanisms (which would then be MAY support) or deprecate old >>> algorithms (which would then be MUST NOT support?). I think the group >>> should also have the possibility to create profiles similar to >>> RFC7321, RFC4307bis, and TLS 1.3 Section 8 (i.e MUST, SHOULD, MAY, >>> SHOULD NOT, MUST NOT support…). >> >> If the WG had consensus to e.g. propose " as a MUST for SSH" >> for some reasonable then I think that would be fine and >> within the charter scope. Do we need to add text to say that? If >> so, what? > > I think it would be good to clarify that, suggestion: > > OLD: > The CURDLE working group is chartered to add a small set of cryptographic > mechanisms to some IETF protocols, and to deprecate old algorithms where > there > is IETF consensus to do so. > > > NEW: > The CURDLE working group is chartered to add a small set of cryptographic > mechanisms to some IETF protocols, and to make implementation requirements > including > deprecation of old algorithms where there is IETF consensus to do so. That'd work for me. I'll wait and add it tomorrow(ish) in case folks have better wording or objections. Cheers, S. > > > >> >>> I have recently driven a profile >>> update of all 3GPP usage of IETF Security Protocols as well as an >>> internal update of Ericsson's usage of security mechanisms. >>> Implementation Requirements and Usage Guidance for at least SSH and >>> PKIX would be very useful to have. >>> >>> Some editorials: “and JSON” -> "and JOSE" “AES-CCM[4]” -> “AES-CCM >> >> Ta, >> S. >> >> >>> [4]" >>> >>> Cheers, John >>> >>> On 11/18/15 12:23 PM, Stephen Farrell wrote: >>>> Hiya, >>>> >>>> Following on from the earlier discussion about adding curves etc. a >>>> few folks (*) helped Kathleen and I craft an initial cut at charter >>>> text. [1] >>>> >>>> I think we have people (well, mostly Simon:-) to do the editing >>>> work for this. >>>> >>>> If you'd be willing to be a chair, please send an offlist mail to >>>> Kathleen and I. >>>> >>>> If you think this is useful and would review documents please >>>> respond to this mail saying so. I'd like to see that we have enough >>>> folks interested to make this work. >>>> >>>> If you have changes to charter text to suggest please do so, >>>> preferably in OLD/NEW form. >>>> >>>> If you think this is a bad idea, I'm sure you'll not be shy in >>>> saying so too:-) >>>> >>>> If there's not enough interest or if there're sound objections >>>> then we can abandon the idea and fall back to processing this stuff >>>> more slowly and more ad-hoc as AD sponsored drafts. (The main point >>>> of curdle is to be more organised and hopefully quicker at this.) >>>> >>>> Thanks, S. >>>> >>>> [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ >>>> >>>> (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and Sean >>>> Turner for help with the text. The fault however is mine, if it's >>>> bad text or a dumb idea:-) >>>> >>>> _______________________________________________ saag mailing list >>>> saag@ietf.org https://www.ietf.org/mailman/listinfo/saag >>>> >>> >>> >>> JOHN MATTSSON MSc Engineering Physics, MSc Business Administration >>> and Economics Ericsson IETF Security Coordinator Senior Researcher, >>> Security >>> >>> Ericsson AB Ericsson Research Färögatan 6 SE-164 80 Stockholm, >>> Sweden Phone +46 10 71 43 501 SMS/MMS +46 76 11 53 501 >>> john.mattsson@ericsson.com >>> www.ericsson.com >>> >>> >>> [http://www.ericsson.com/] >>> >>> This Communication is Confidential. We only send and receive email on >>> the basis of the terms set out >>> >>> atwww.ericsson.com/email_disclaimer>> mer> >>> >>> >>> >>> >>> _______________________________________________ saag mailing list >>> saag@ietf.org https://www.ietf.org/mailman/listinfo/saag >>> > From nobody Wed Nov 18 10:35:51 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1501A21AE for ; Wed, 18 Nov 2015 10:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 9R-UNuA2xmz8 for ; Wed, 18 Nov 2015 10:35:49 -0800 (PST) Received: from hoffman.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 083E61A21AC for ; Wed, 18 Nov 2015 10:35:49 -0800 (PST) Received: from [10.32.60.56] (50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id tAIIZgl1006947 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Nov 2015 11:35:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-110.dsl.dynamic.fusionbroadband.com [50.1.98.110] claimed to be [10.32.60.56] From: "Paul Hoffman" To: "Stephen Farrell" Date: Wed, 18 Nov 2015 10:35:42 -0800 Message-ID: <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> In-Reply-To: <564CAF70.3030605@cs.tcd.ie> References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 18:35:50 -0000 On 18 Nov 2015, at 9:03, Stephen Farrell wrote: > On 18/11/15 16:48, Paul Hoffman wrote: >> How can this WG be "short-lived" when you have the following in the >> charter? > > My assumption (possibly wrong) was that the curdle wg would do > the work on adding things and if, whilst doing that, they find > stuff that can be deprecated, then they can choose to go do the > work to deprecate stuff. But that the plan is to close when the > new stuff is done. If that's the plan, it should be stated in the charter. Some people in our community really like to focus on deprecating outdated algorithms and garnering publicity for shaming those who continue to use them. A different thought is to have two WGs: curdle for "add new EC" and depoldalg for "deprecating old algorithms". The latter could be given a one-year charter. > My intent fwiw was not that this wg hang around for ever figuring > out what to deprecate next. With the NSA's newly-stated belief that 2048-bit RSA/DH is not good enough for protection against post-quantum crypto (I'm purposely not giving my opinion on any part of that statement...), you probably need to be firmer in stating what is out of scope for deprecation. > Does that help? If so, figuring out how to say it better would > be an improvement. (Any suggestions?) See above. There might even be a third "depalgforpqc" WG. >> As the CURDLE working group will be handling changes to protocols >> and >> registries some of which include what are now considered outdated >> algorithm >> options, the working group can also choose to propose deprecation of >> such >> algorithms. Such deprecation needs to be done with care, ensuring >> that >> interoperability and the needs of existing implementers and >> deployments are >> properly considered. Where deprecation is practical, the working >> group is >> encouraged to deprecate. >> >> Arguing about what is outdated always takes a long time. "It's still >> good enough for the next five years." "No one ever changes their >> software so we need to do this early." "We have people who need to >> use >> this for another ten years and they understand the consequences." "We >> can ignore this small set of users." "We cannot ignore this small set >> of >> users." "We got rid of that algorithm in TLS and it didn't hurt." >> "Our >> users are different than web browser users." "The charter says we >> must >> do this 'with care' and you are being careless." "No, you're just >> being >> stubborn." > > We would have that argument again yes. Maybe we'd get better at > handling it if we do it in a more concentrated fashion? I'm not > sure we would, but I figure it may be worth trying, esp as I'd > bet that we do find things we'd want to deprecate. We haven't gotten any better in the past 15 years of experience with that. I'm willing to bet we're doing our best now, and that our best includes thrashing about this topic every time it comes up. >> Without that paragraph in the charter, I'm pretty sure consensus will >> be >> easy. > > Do you mean consensus on the charter? (I think you do, just checking) Yes. --Paul Hoffman From nobody Wed Nov 18 11:53:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92B1A92FB for ; Wed, 18 Nov 2015 11:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 PeJiurgLWgew for ; Wed, 18 Nov 2015 11:53:36 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 5B4341A92E2 for ; Wed, 18 Nov 2015 11:53:36 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAIJrQHk017896 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 18 Nov 2015 20:53:27 +0100 From: Simon Josefsson To: "Paul Hoffman" References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151118:paul.hoffman@vpnc.org::thkUcKNHrDwSHaDo:4Pq9 X-Hashcash: 1:22:151118:saag@ietf.org::Yo8UMOrDHkQpoiqo:MfO5 X-Hashcash: 1:22:151118:stephen.farrell@cs.tcd.ie::qTRJRkh00jLAeENa:IKos Date: Wed, 18 Nov 2015 20:53:25 +0100 In-Reply-To: <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> (Paul Hoffman's message of "Wed, 18 Nov 2015 10:35:42 -0800") Message-ID: <87twoj13uy.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 19:53:39 -0000 --=-=-= Content-Type: text/plain "Paul Hoffman" writes: >> My intent fwiw was not that this wg hang around for ever figuring >> out what to deprecate next. > > With the NSA's newly-stated belief that 2048-bit RSA/DH is not good > enough for protection against post-quantum crypto (I'm purposely not > giving my opinion on any part of that statement...), you probably need > to be firmer in stating what is out of scope for deprecation. I suppose the intention is to deprecate "obviously bad" algorithms like rc2, rc4, md2, md4, md5, collision-resistant uses of sha1, single-des, small block (<128b) size block ciphers, <=1024 bit DSA/RSA/DH, <224bit ECC, etc, should we realize any of these examples when going through protocols. Borderline cases may include HMAC-MD5 and 224-bit ECC. I am, though, also uncertain there will be a lot of overlap between the activity of removing old algorithms and introducing new algorithm. I believe the idea that these activities are related stem from the IMO incorrect notion that adding new ECC curves to existing protocols is mostly about allocating code points -- I believe we've seen with SSH, JSON, TLS, PKIX and OpenPGP already that there are several other difficulties (e.g., alignment with ECDSA specs). If indeed WG chartering is low-cost, having a separate WG to deal with updating of old specs may be cleaner. I don't believe recommending against 2048-bit RSA/DH will do any good. It will slow adoption of decent crypto where weak crypto is deployed. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWTNc1AAoJEIYLf7sy+BGduWEIAK1LKk6GSwAVPQGSWfXfPtkM RCebFmbzIBachrjYKyDtssnkmWZag3g5hRKDvbbInPO+rMmykUilIeg6dH+ByrBl lQUDEj/s+rFSIdPh2dw3VLhrsr6oLpUb1VgSWWmU47+zy/9gb8XAIK1HcEfOaZoH EggX3Eh9v/6FFdI8yFMHGHr/DTLGjc1hw9LueTsPnH5xWSkdM7tuTxZElAs9jtrj b07FmIpcTLoXqbuJwlZsUPhAZsJaNoaliH4nIBjU93bMSPwzwqVpqzuoCP/bAMY7 0kp2o+QrzqEU8L5vG7sdgzBPUR8N1iv4oBX2Wt1MLufSsS4gyWyoosGXf7muG/Y= =xQpB -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 18 11:59:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4731AC3FE for ; Wed, 18 Nov 2015 11:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc1UsL3dZ2yM for ; Wed, 18 Nov 2015 11:59:00 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id CC56C1A9047 for ; Wed, 18 Nov 2015 11:59:00 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 779AEF24061 for ; Wed, 18 Nov 2015 14:58:50 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id FFjZgeliZZ47 for ; Wed, 18 Nov 2015 14:57:20 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7BF0FF2406E for ; Wed, 18 Nov 2015 14:58:24 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Russ Housley In-Reply-To: Date: Wed, 18 Nov 2015 14:58:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564C5FCC.8080107@cs.tcd.ie> To: IETF SAAG X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 19:59:02 -0000 > How can this WG be "short-lived" when you have the following in the = charter? >=20 > As the CURDLE working group will be handling changes to protocols and > registries some of which include what are now considered outdated = algorithm > options, the working group can also choose to propose deprecation of = such > algorithms. Such deprecation needs to be done with care, ensuring = that > interoperability and the needs of existing implementers and = deployments are > properly considered. Where deprecation is practical, the working group = is > encouraged to deprecate. Good point. Maybe this group should only tackle the registries and the = conventions for using existing protocol fields. If a change to the = protocol is needed, maybe that should go to a separate protocol = maintenance group. Russ From nobody Wed Nov 18 12:12:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6DF1ACD62 for ; Wed, 18 Nov 2015 12:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwPhX29xoy75 for ; Wed, 18 Nov 2015 12:12:07 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6FF1ACD5B for ; Wed, 18 Nov 2015 12:12:06 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-dc-564cdb94a489 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B1.5F.29154.49BDC465; Wed, 18 Nov 2015 21:12:04 +0100 (CET) Received: from ESESSMB310.ericsson.se ([169.254.10.15]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 18 Nov 2015 21:12:03 +0100 From: John Mattsson To: Simon Josefsson , Paul Hoffman Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIiMUyxwHZkFPGkGCMx9vxuLjV56iCtIAgAAmk0WAAAUZgA== Date: Wed, 18 Nov 2015 20:12:03 +0000 Message-ID: References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> <87twoj13uy.fsf@latte.josefsson.org> In-Reply-To: <87twoj13uy.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: <5D824E786C99D54886688E9CC140CE52@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7nO6U2z5hBlPX8lrcWv+F1WJKfyeT xb0tl9gdmD2WLPnJ5DHzzEV2j8+zrzIHMEdx2aSk5mSWpRbp2yVwZcxZfpq14JxExdTnlxgb GP+IdzFyckgImEjsO/GJBcIWk7hwbz0biC0kcJhR4uN6xi5GLiB7CaNE5/U3YEVsAgYSc/c0 gBWJCARKfH22jxnEZhZQlnj75wkTiC0MVLNx6TYmiBpDiYO79jND2E4SkzfsZQWxWQRUJXoW 7QKbwytgLvF1Tws7xLILjBJL1k8Da+YEat7z4xxYAyPQdd9PrWGCWCYucevJfCaIqwUkluw5 zwxhi0q8fPwPqJ6DQ1RAT2LPckmIsJLEotufmUDCzAKaEut36UNMsZb4NOUn1PmKElO6H7JD nCMocXLmE5YJjBKzkCybhdA9C0n3LCTds5B0L2BkXcUoWpxaXJybbmSkl1qUmVxcnJ+nl5da sokRGJcHt/y22sF48LnjIUYBDkYlHt6Cjd5hQqyJZcWVuYcYJTiYlUR4yy75hAnxpiRWVqUW 5ccXleakFh9ilOZgURLnbWZ6ECokkJ5YkpqdmlqQWgSTZeLglGpgXPp68Q3W+O2rnMxMEy7x le/uvLFqv18940rv2JwT3yamOqZtNA5Va7N89S5P5f1ajtdX7rySWXHcxtlfeuvTvxsWffTb J1ugOjFp1ccmDUMNkx71Z9MXr7HaMD9lf3Wh2/wonQfrHk41N+9YJFomWOkb1JL7aXF5+bEt s7Ki2vrvNa1dkbm7TYmlOCPRUIu5qDgRAHbSMyXHAgAA Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:12:08 -0000 DQpPbiAxOC8xMS8xNSAyMDo1MywgInNhYWcgb24gYmVoYWxmIG9mIFNpbW9uIEpvc2Vmc3NvbiIN CjxzYWFnLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHNpbW9uQGpvc2Vmc3Nvbi5vcmc+ IHdyb3RlOg0KDQo+IlBhdWwgSG9mZm1hbiIgPHBhdWwuaG9mZm1hbkB2cG5jLm9yZz4gd3JpdGVz Og0KPg0KPj4+IE15IGludGVudCBmd2l3IHdhcyBub3QgdGhhdCB0aGlzIHdnIGhhbmcgYXJvdW5k IGZvciBldmVyIGZpZ3VyaW5nDQo+Pj4gb3V0IHdoYXQgdG8gZGVwcmVjYXRlIG5leHQuDQo+Pg0K Pj4gV2l0aCB0aGUgTlNBJ3MgbmV3bHktc3RhdGVkIGJlbGllZiB0aGF0IDIwNDgtYml0IFJTQS9E SCBpcyBub3QgZ29vZA0KPj4gZW5vdWdoIGZvciBwcm90ZWN0aW9uIGFnYWluc3QgcG9zdC1xdWFu dHVtIGNyeXB0byAoSSdtIHB1cnBvc2VseSBub3QNCj4+IGdpdmluZyBteSBvcGluaW9uIG9uIGFu eSBwYXJ0IG9mIHRoYXQgc3RhdGVtZW50Li4uKSwgeW91IHByb2JhYmx5IG5lZWQNCj4+IHRvIGJl IGZpcm1lciBpbiBzdGF0aW5nIHdoYXQgaXMgb3V0IG9mIHNjb3BlIGZvciBkZXByZWNhdGlvbi4N Cg0KSSB0aGluayB0aGUgY3VycmVudCBmb3JtdWxhdGlvbiDigJx3aGVyZSB0aGVyZSBpcyBJRVRG IGNvbnNlbnN1cyB0byBkbyBzb+KAnQ0KaXMgcXVpdGUgZ29vZC4gV2hlbiB0byBkZXByZWNhdGUg ZGVwZW5kcyBvbiBzbyBtYW55IGZhY3RvcnMgc3VjaCBhcyBuZXcNCmNyeXB0YW5hbHlzaXMgYW5k IHRoZSBzdXBwb3J0IG9mIG5ldyBhbGdvcml0aG1zLg0KDQpJIHRoaW5rIGJhc2ljYWxseSBldmVy eWJvZHkgaXMgYmVsaWV2aW5nIHRoYXQgUlNBL0RIL0VDQyBpcyB1dHRlcmx5IGJyb2tlbg0KYnkg cXVhbnR1bSBjb21wdXRlcnMgZm9yIGFueSB1c2FibGUga2V5IGxlbmd0aHMuIEJvdGggTklTVCBh bmQgRUNSWVBUDQpyZWNvbW1lbmRzIHRvIHN0b3AgdXNpbmcgMjA0OC1SU0EvREggbm8gbGF0ZXIg dGhhbiAyMDMwIGJ1dCB0aGF0IGlzIG5vdA0KYmVjYXVzZSBvZiBxdWFudHVtIGNvbXB1dGVycy4N Cg0KPkkgc3VwcG9zZSB0aGUgaW50ZW50aW9uIGlzIHRvIGRlcHJlY2F0ZSAib2J2aW91c2x5IGJh ZCIgYWxnb3JpdGhtcyBsaWtlDQo+cmMyLCByYzQsIG1kMiwgbWQ0LCBtZDUsIGNvbGxpc2lvbi1y ZXNpc3RhbnQgdXNlcyBvZiBzaGExLCBzaW5nbGUtZGVzLA0KPnNtYWxsIGJsb2NrICg8MTI4Yikg c2l6ZSBibG9jayBjaXBoZXJzLCA8PTEwMjQgYml0IERTQS9SU0EvREgsIDwyMjRiaXQNCj5FQ0Ms IGV0Yywgc2hvdWxkIHdlIHJlYWxpemUgYW55IG9mIHRoZXNlIGV4YW1wbGVzIHdoZW4gZ29pbmcg dGhyb3VnaA0KPnByb3RvY29scy4gIEJvcmRlcmxpbmUgY2FzZXMgbWF5IGluY2x1ZGUgSE1BQy1N RDUgYW5kIDIyNC1iaXQgRUNDLg0KDQorMSAoQnV0IGFkZCB0d28ta2V5IHRyaXBwbGUtZGVzIGFu ZCBjaGFuZ2UgdG8gPDIwNDggYml0IERTQS9SU0EvREgpLg0KDQo+SSBhbSwgdGhvdWdoLCBhbHNv IHVuY2VydGFpbiB0aGVyZSB3aWxsIGJlIGEgbG90IG9mIG92ZXJsYXAgYmV0d2VlbiB0aGUNCj5h Y3Rpdml0eSBvZiByZW1vdmluZyBvbGQgYWxnb3JpdGhtcyBhbmQgaW50cm9kdWNpbmcgbmV3IGFs Z29yaXRobS4gIEkNCj5iZWxpZXZlIHRoZSBpZGVhIHRoYXQgdGhlc2UgYWN0aXZpdGllcyBhcmUg cmVsYXRlZCBzdGVtIGZyb20gdGhlIElNTw0KPmluY29ycmVjdCBub3Rpb24gdGhhdCBhZGRpbmcg bmV3IEVDQyBjdXJ2ZXMgdG8gZXhpc3RpbmcgcHJvdG9jb2xzIGlzDQo+bW9zdGx5IGFib3V0IGFs bG9jYXRpbmcgY29kZSBwb2ludHMgLS0gSSBiZWxpZXZlIHdlJ3ZlIHNlZW4gd2l0aCBTU0gsDQo+ SlNPTiwgVExTLCBQS0lYIGFuZCBPcGVuUEdQIGFscmVhZHkgdGhhdCB0aGVyZSBhcmUgc2V2ZXJh bCBvdGhlcg0KPmRpZmZpY3VsdGllcyAoZS5nLiwgYWxpZ25tZW50IHdpdGggRUNEU0Egc3BlY3Mp LiAgSWYgaW5kZWVkIFdHDQo+Y2hhcnRlcmluZyBpcyBsb3ctY29zdCwgaGF2aW5nIGEgc2VwYXJh dGUgV0cgdG8gZGVhbCB3aXRoIHVwZGF0aW5nIG9mDQo+b2xkIHNwZWNzIG1heSBiZSBjbGVhbmVy Lg0KPg0KPkkgZG9uJ3QgYmVsaWV2ZSByZWNvbW1lbmRpbmcgYWdhaW5zdCAyMDQ4LWJpdCBSU0Ev REggd2lsbCBkbyBhbnkgZ29vZC4NCj5JdCB3aWxsIHNsb3cgYWRvcHRpb24gb2YgZGVjZW50IGNy eXB0byB3aGVyZSB3ZWFrIGNyeXB0byBpcyBkZXBsb3llZC4NCg0KQWdyZWUsIHRoZSBjdXJyZW50 IGZvY3VzIHNob3VsZCBiZSB0byB1cGdyYWRlIDwyMDQ4LWJpdCBSU0EvREggdG8gMjA0OC1iaXQN ClJTQS9ESC4NCg0KL0pvaG4NCg0K From nobody Wed Nov 18 12:16:34 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9461AD069 for ; Wed, 18 Nov 2015 12:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1Y8zvMHExZ4 for ; Wed, 18 Nov 2015 12:16:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3B81ACEF7 for ; Wed, 18 Nov 2015 12:16:31 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7CC4028494E; Wed, 18 Nov 2015 20:16:30 +0000 (UTC) Date: Wed, 18 Nov 2015 20:16:30 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20151118201630.GD18315@mournblade.imrryr.org> References: <564C5FCC.8080107@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:16:33 -0000 On Wed, Nov 18, 2015 at 02:58:23PM -0500, Russ Housley wrote: > > How can this WG be "short-lived" when you have the following in the charter? > > > > As the CURDLE working group will be handling changes to protocols and > > registries some of which include what are now considered outdated algorithm > > options, the working group can also choose to propose deprecation of such > > algorithms. Such deprecation needs to be done with care, ensuring that > > interoperability and the needs of existing implementers and deployments are > > properly considered. Where deprecation is practical, the working group is > > encouraged to deprecate. > > Good point. Maybe this group should only tackle the registries and the > conventions for using existing protocol fields. If a change to the protocol > is needed, maybe that should go to a separate protocol maintenance group. I don't see why deprecating where appropriate makes the group "long-lived". It might take longer, but it is not an indefinite commitment. ------------------ For example, with DNSSEC, if new algorithm IDS are added for the new curves, it would I think be time to do a bit of house-keeping and explicitly designate some algorithms as outdated. With DNSSEC too many algorithms serve only to create islands of interoperability. So it may be time to update: https://tools.ietf.org/html/rfc6944#section-2.3 which does not at present distinguish between "implement" (in validating and authoritative servers) and "publish" (deploy DS/DNSKEY records with a given algorithm). To phase out old or introduce new algorithms, they need to be in a SHOULD IMPLEMENT state for some time with a SHOULD NOT publish, so that they can later be moved to not implemented or published respectively. Specifically, I'd propose that algorithms 3 and 6 should be deprecated (MAY implement, SHOULD NOT publish). I'd also like to see algorithm 12 join their ranks. ------------------ The point of the above is not (in this thread) to digress into the gory details of DNSSEC, but rather to highlight that considerations of the complete life-cycle of algorithms come into play, so that we don't just keep on adding, and never removing. -- Viktor. From nobody Wed Nov 18 12:33:56 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B491B2B31 for ; Wed, 18 Nov 2015 12:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mUYSvXX5Iei for ; Wed, 18 Nov 2015 12:33:53 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (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 ED13B1B2B18 for ; Wed, 18 Nov 2015 12:33:52 -0800 (PST) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tAIKXm5v012297 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Nov 2015 15:33:51 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com tAIKXm5v012297 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1447878831; bh=RuyCUz5yMqfyiWW55moP5Mz3BjM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=oGpCubDI0P5WiRCY8iKUrbuZV8cO27h2Gul0r5ms+YmmTfwwYwJ3/JUvszFV/0vW9 Az6xwQ9h+jCLSl2alaJ7i0f9idnZvgym2RVn/HyPLI1Ykfobx6HbhSYrnFisDKTPLq rAmoiDaCY3XiqjMxyTaWEwLBtb7uNEgdbhVyfniE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com tAIKXm5v012297 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Wed, 18 Nov 2015 15:33:43 -0500 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tAIKXjPE030396 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Nov 2015 15:33:45 -0500 Received: from MXHUB104.corp.emc.com (10.253.58.16) by mxhub40.corp.emc.com (128.222.70.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 18 Nov 2015 15:33:44 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.97]) by MXHUB104.corp.emc.com ([::1]) with mapi id 14.03.0266.001; Wed, 18 Nov 2015 15:33:44 -0500 From: "Black, David" To: Paul Hoffman Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIfOmOAMCiL9VE06VV0LIwrXJsp6iAnCtgABtVgD//7ck4A== Date: Wed, 18 Nov 2015 19:19:42 +0000 Message-ID: References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> In-Reply-To: <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:33:55 -0000 > A different thought is to have two WGs: curdle for "add new EC" and > depoldalg for "deprecating old algorithms". The latter could be given a > one-year charter Surely we can be more creative - "die3" [for "Die!Die!Die!"] seems appropri= ate :-). Seriously, I like the idea of separate WGs for clearly needed additions vs. debates on what to remove when. Thanks, --David > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Wednesday, November 18, 2015 1:36 PM > To: Stephen Farrell > Cc: saag@ietf.org > Subject: Re: [saag] potential new wg - curdle... >=20 > On 18 Nov 2015, at 9:03, Stephen Farrell wrote: >=20 > > On 18/11/15 16:48, Paul Hoffman wrote: > >> How can this WG be "short-lived" when you have the following in the > >> charter? > > > > My assumption (possibly wrong) was that the curdle wg would do > > the work on adding things and if, whilst doing that, they find > > stuff that can be deprecated, then they can choose to go do the > > work to deprecate stuff. But that the plan is to close when the > > new stuff is done. >=20 > If that's the plan, it should be stated in the charter. Some people in > our community really like to focus on deprecating outdated algorithms > and garnering publicity for shaming those who continue to use them. >=20 > A different thought is to have two WGs: curdle for "add new EC" and > depoldalg for "deprecating old algorithms". The latter could be given a > one-year charter. >=20 > > My intent fwiw was not that this wg hang around for ever figuring > > out what to deprecate next. >=20 > With the NSA's newly-stated belief that 2048-bit RSA/DH is not good > enough for protection against post-quantum crypto (I'm purposely not > giving my opinion on any part of that statement...), you probably need > to be firmer in stating what is out of scope for deprecation. >=20 > > Does that help? If so, figuring out how to say it better would > > be an improvement. (Any suggestions?) >=20 > See above. There might even be a third "depalgforpqc" WG. >=20 > >> As the CURDLE working group will be handling changes to protocols > >> and > >> registries some of which include what are now considered outdated > >> algorithm > >> options, the working group can also choose to propose deprecation of > >> such > >> algorithms. Such deprecation needs to be done with care, ensuring > >> that > >> interoperability and the needs of existing implementers and > >> deployments are > >> properly considered. Where deprecation is practical, the working > >> group is > >> encouraged to deprecate. > >> > >> Arguing about what is outdated always takes a long time. "It's still > >> good enough for the next five years." "No one ever changes their > >> software so we need to do this early." "We have people who need to > >> use > >> this for another ten years and they understand the consequences." "We > >> can ignore this small set of users." "We cannot ignore this small set > >> of > >> users." "We got rid of that algorithm in TLS and it didn't hurt." > >> "Our > >> users are different than web browser users." "The charter says we > >> must > >> do this 'with care' and you are being careless." "No, you're just > >> being > >> stubborn." > > > > We would have that argument again yes. Maybe we'd get better at > > handling it if we do it in a more concentrated fashion? I'm not > > sure we would, but I figure it may be worth trying, esp as I'd > > bet that we do find things we'd want to deprecate. >=20 > We haven't gotten any better in the past 15 years of experience with > that. I'm willing to bet we're doing our best now, and that our best > includes thrashing about this topic every time it comes up. >=20 > >> Without that paragraph in the charter, I'm pretty sure consensus will > >> be > >> easy. > > > > Do you mean consensus on the charter? (I think you do, just checking) >=20 > Yes. >=20 > --Paul Hoffman >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Nov 18 12:43:21 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCB21B2D21 for ; Wed, 18 Nov 2015 12:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epmZXRN9nyqr for ; Wed, 18 Nov 2015 12:43:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1DA1B2D1F for ; Wed, 18 Nov 2015 12:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5645; q=dns/txt; s=iport; t=1447879398; x=1449088998; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=V55BoYXusU8gYNKrzBlI3fwonDsK5+0MIGZqKnWFXgI=; b=BYVNuNpCCH/sgknx/VrvLssdOli7ZS1LPeFL0mdbo3jCDGni8BRuW1yu Di7dAuvsVk1CtZNFofBzdshHUJnJCBhQJ3mNHpAcdzmdS+gOfmck8qZaN pFh/ugQ4VpEJFRpf0XkpPYhXJpgS2cRpZA9XMUS7JIrNk/sh1FpABBL49 8=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AgCC4UxW/40NJK1egztTbwa+Yg6BZ?= =?us-ascii?q?RcKgj6DMAKBUDgUAQEBAQEBAYEKhDQBAQEDAQEBAWsLBQcEAgEIEQQBAQEnByc?= =?us-ascii?q?LFAkIAgQOBQ4GiBIIDb95AQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEiGSBaIEGi?= =?us-ascii?q?CSBFQWWSgGCVoFgiHScRAEfAUOCER2BVnKEBYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,314,1444694400"; d="asc'?scan'208";a="51590940" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2015 20:43:17 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tAIKhHr6010979 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Nov 2015 20:43:17 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 18 Nov 2015 14:43:16 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Wed, 18 Nov 2015 14:43:16 -0600 From: "Matt Miller (mamille2)" To: "Black, David" Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIfOmlyKJgLJdVkey/8gk22uGFJ6iAlsegAB+LgCAAAxLAIAAF1iA Date: Wed, 18 Nov 2015 20:43:16 +0000 Message-ID: References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.24.52] Content-Type: multipart/signed; boundary="Apple-Mail=_E1546FD3-2F92-465A-ACB3-3DBBB64C8981"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Paul Hoffman , "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 20:43:20 -0000 --Apple-Mail=_E1546FD3-2F92-465A-ACB3-3DBBB64C8981 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 18, 2015, at 12:19, Black, David wrote: >=20 >> A different thought is to have two WGs: curdle for "add new EC" and >> depoldalg for "deprecating old algorithms". The latter could be given = a >> one-year charter >=20 > Surely we can be more creative - "die3" [for "Die!Die!Die!"] seems = appropriate :-). >=20 Or "Deprecating Ineffective Algorithms from Frameworks" (DIAF). > Seriously, I like the idea of separate WGs for clearly needed = additions vs. > debates on what to remove when. I think separating them makes sense, too. -- - m&m Matt Miller Cisco Systems, Inc. >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Paul Hoffman >> Sent: Wednesday, November 18, 2015 1:36 PM >> To: Stephen Farrell >> Cc: saag@ietf.org >> Subject: Re: [saag] potential new wg - curdle... >>=20 >> On 18 Nov 2015, at 9:03, Stephen Farrell wrote: >>=20 >>> On 18/11/15 16:48, Paul Hoffman wrote: >>>> How can this WG be "short-lived" when you have the following in the >>>> charter? >>>=20 >>> My assumption (possibly wrong) was that the curdle wg would do >>> the work on adding things and if, whilst doing that, they find >>> stuff that can be deprecated, then they can choose to go do the >>> work to deprecate stuff. But that the plan is to close when the >>> new stuff is done. >>=20 >> If that's the plan, it should be stated in the charter. Some people = in >> our community really like to focus on deprecating outdated algorithms >> and garnering publicity for shaming those who continue to use them. >>=20 >> A different thought is to have two WGs: curdle for "add new EC" and >> depoldalg for "deprecating old algorithms". The latter could be given = a >> one-year charter. >>=20 >>> My intent fwiw was not that this wg hang around for ever figuring >>> out what to deprecate next. >>=20 >> With the NSA's newly-stated belief that 2048-bit RSA/DH is not good >> enough for protection against post-quantum crypto (I'm purposely not >> giving my opinion on any part of that statement...), you probably = need >> to be firmer in stating what is out of scope for deprecation. >>=20 >>> Does that help? If so, figuring out how to say it better would >>> be an improvement. (Any suggestions?) >>=20 >> See above. There might even be a third "depalgforpqc" WG. >>=20 >>>> As the CURDLE working group will be handling changes to protocols >>>> and >>>> registries some of which include what are now considered outdated >>>> algorithm >>>> options, the working group can also choose to propose deprecation = of >>>> such >>>> algorithms. Such deprecation needs to be done with care, ensuring >>>> that >>>> interoperability and the needs of existing implementers and >>>> deployments are >>>> properly considered. Where deprecation is practical, the working >>>> group is >>>> encouraged to deprecate. >>>>=20 >>>> Arguing about what is outdated always takes a long time. "It's = still >>>> good enough for the next five years." "No one ever changes their >>>> software so we need to do this early." "We have people who need to >>>> use >>>> this for another ten years and they understand the consequences." = "We >>>> can ignore this small set of users." "We cannot ignore this small = set >>>> of >>>> users." "We got rid of that algorithm in TLS and it didn't hurt." >>>> "Our >>>> users are different than web browser users." "The charter says we >>>> must >>>> do this 'with care' and you are being careless." "No, you're just >>>> being >>>> stubborn." >>>=20 >>> We would have that argument again yes. Maybe we'd get better at >>> handling it if we do it in a more concentrated fashion? I'm not >>> sure we would, but I figure it may be worth trying, esp as I'd >>> bet that we do find things we'd want to deprecate. >>=20 >> We haven't gotten any better in the past 15 years of experience with >> that. I'm willing to bet we're doing our best now, and that our best >> includes thrashing about this topic every time it comes up. >>=20 >>>> Without that paragraph in the charter, I'm pretty sure consensus = will >>>> be >>>> easy. >>>=20 >>> Do you mean consensus on the charter? (I think you do, just = checking) >>=20 >> Yes. >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_E1546FD3-2F92-465A-ACB3-3DBBB64C8981 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWTOLkAAoJEDWi+S0W7cO1weIH/2iqaeWAvok/0U4LKhtj54eb 2BqMQJDdYvOZa12MmN4cb3mCmL4X4+lxjQn1XP5mE3a5hK6A0IOJuAKQXZMME2ro pqs8PPB/2SOacgIile26rYlCrX/uh6o9y2yJ3thnzZcz5MW+oJrE4hCTTsE7UD3+ EIlzjjkN3xV+IVoZ1/pnYb129uC+MMG0+Sy7npORkzkpCipQmP2z4up49cjy8Nn/ sSVnz9t5lTLiCiWbe79RCruAWKKs0JAk/YdRKoq196Z+ajhm+QWGk6mNPGGCmr5x 1Y1EHxQUvicQLRqhCzu5+XaLzRmzYtbd56BU5alaQkkZa688ZPjKA4CsLb7t1KU= =zZAo -----END PGP SIGNATURE----- --Apple-Mail=_E1546FD3-2F92-465A-ACB3-3DBBB64C8981-- From nobody Wed Nov 18 14:27:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB901B31F4 for ; Wed, 18 Nov 2015 14:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=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 YL4jJvEr7yVk for ; Wed, 18 Nov 2015 14:27:55 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c: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 510C61B314C for ; Wed, 18 Nov 2015 14:27:55 -0800 (PST) Received: by wmdw130 with SMTP id w130so217874979wmd.0 for ; Wed, 18 Nov 2015 14:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zgdT1dXEMxqIP58cpD9v0NFy3lzRJxDWfvm3BI5iaLo=; b=t4oM3kLyErII8YDDxaPMKynR0Eke6O425td+ccyWb0EOac72Q7novNZLV6H9Znl7Bd z/J9UEPkFGPOHVxyJ3cc0kj/eqx/YR902RB9l6ANc2kk2SJoCb/zjituUTL5zfu1kJGl ztkaqwgnbUU7724ewiyJjGmiLVXKvtls9kOOxNAKKp4A9oIrG38Y0Ia/vKwQecpejI18 mhj9aui2TWGoZgcglWbYHDf8BEsaFed2lheNp1tVVTes4AQ5llNH46Qj/wa5QCZKlm+H SeoAXcPHyi/EZDQdNx1/Rn0rOwHQ5wQFp92+lOsZSMDlf+WxVJ1bTNFcHdr7PSG16R7p hxOg== X-Received: by 10.194.134.135 with SMTP id pk7mr4464848wjb.111.1447885673852; Wed, 18 Nov 2015 14:27:53 -0800 (PST) Received: from [192.168.1.10] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id 143sm3283626wmv.18.2015.11.18.14.27.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 18 Nov 2015 14:27:52 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Yoav Nir In-Reply-To: <564C5FCC.8080107@cs.tcd.ie> Date: Thu, 19 Nov 2015 00:27:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8BAFE0B6-3793-4F20-A32F-4778CF19CC53@gmail.com> References: <564C5FCC.8080107@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 22:27:56 -0000 So speaking only for the deprecate part, I=E2=80=99m wondering if it = should be in-scope to scour IANA registries looking for obscure = algorithms to deprecate. Looking at the TLS and IPsec registries I can find RC5, IDEA, CAST, = Blowfish, Tiger, and of course some national ciphers such as camellia, = ARIA, SEED, and GOST. I=E2=80=99m pretty sure we don=E2=80=99t want to = go there with the national ciphers, but deprecating a bunch of the = others that are rarely if ever in use seems like a good idea. Yoav > On 18 Nov 2015, at 1:23 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Following on from the earlier discussion about adding curves > etc. a few folks (*) helped Kathleen and I craft an initial cut > at charter text. [1] >=20 > I think we have people (well, mostly Simon:-) to do the editing > work for this. >=20 > If you'd be willing to be a chair, please send an offlist mail > to Kathleen and I. >=20 > If you think this is useful and would review documents please > respond to this mail saying so. I'd like to see that we have > enough folks interested to make this work. >=20 > If you have changes to charter text to suggest please do so, > preferably in OLD/NEW form. >=20 > If you think this is a bad idea, I'm sure you'll not be shy in > saying so too:-) >=20 > If there's not enough interest or if there're sound objections then > we can abandon the idea and fall back to processing this stuff more > slowly and more ad-hoc as AD sponsored drafts. (The main point of > curdle is to be more organised and hopefully quicker at this.) >=20 > Thanks, > S. >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ >=20 > (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and > Sean Turner for help with the text. The fault however is mine, > if it's bad text or a dumb idea:-) >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Nov 18 15:29:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A681B3381 for ; Wed, 18 Nov 2015 15:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.286 X-Spam-Level: X-Spam-Status: No, score=-4.286 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auGObyW7IQU0 for ; Wed, 18 Nov 2015 15:29:23 -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 4EFAB1B3375 for ; Wed, 18 Nov 2015 15:29:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31098BE3E; Wed, 18 Nov 2015 23:29:21 +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 zyOXvhhTPJlB; Wed, 18 Nov 2015 23:29:20 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2A0BCBE33; Wed, 18 Nov 2015 23:29:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447889359; bh=+H2AbwZYDOKZIhf32izxB+CvkfN6IARvEqszQMRKvOg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Qsj4x4tifIAXITKc9r4bSnL4qNPTrmkPzK9lL9PKRPJ1Z4uPDDNQPf8VtnQ9/DKzs fFCpJ43Gzp8k7BfoJrLWVyDip+sNZxUNsnce/hvYhScd2ulP13t0gWIs7yXHqlwA9E /cg3OevxWpTnz31jVG2NEbAgrwrevMP0S0P+6srU= To: Paul Hoffman References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564D09CE.9030808@cs.tcd.ie> Date: Wed, 18 Nov 2015 23:29:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 23:29:26 -0000 On 18/11/15 18:35, Paul Hoffman wrote: > On 18 Nov 2015, at 9:03, Stephen Farrell wrote: > >> On 18/11/15 16:48, Paul Hoffman wrote: >>> How can this WG be "short-lived" when you have the following in the >>> charter? >> >> My assumption (possibly wrong) was that the curdle wg would do >> the work on adding things and if, whilst doing that, they find >> stuff that can be deprecated, then they can choose to go do the >> work to deprecate stuff. But that the plan is to close when the >> new stuff is done. > > If that's the plan, it should be stated in the charter. I agree, but thought it was stated there already. Can you send OLD/NEW text to help? > Some people in > our community really like to focus on deprecating outdated algorithms > and garnering publicity for shaming those who continue to use them. > > A different thought is to have two WGs: curdle for "add new EC" and > depoldalg for "deprecating old algorithms". The latter could be given a > one-year charter. Meh. Frankly I doubt that there'd be willing workers for such a deprecating-only WG, I reckon it'd be far too likely to languish not at the top of anyone's todo list. I'd argue to see what happens with curdle and then maybe revisit if nobody has the energy to deprecate anything in that context we can revisit the issue. But I could be wrong of course. If folks want to write drafts that deprecate things and if there're enough of those queued up I'd be very happy to help start a wg on that topic. So far though, such drafts are fairly rare. And to save scrolling, post-quantum stuff is a topic for cfrg and not (yet) the IETF as far as I'm concerned. So I hope we're ok with the (to me anyway) simpler plan of enabling the work that folks clearly want to get done and also leaving space for deprecating stuff as and when people are feeling the love for a bit of deprecatiion. Cheers, S. > >> My intent fwiw was not that this wg hang around for ever figuring >> out what to deprecate next. > > With the NSA's newly-stated belief that 2048-bit RSA/DH is not good > enough for protection against post-quantum crypto (I'm purposely not > giving my opinion on any part of that statement...), you probably need > to be firmer in stating what is out of scope for deprecation. > >> Does that help? If so, figuring out how to say it better would >> be an improvement. (Any suggestions?) > > See above. There might even be a third "depalgforpqc" WG. > >>> As the CURDLE working group will be handling changes to protocols and >>> registries some of which include what are now considered outdated >>> algorithm >>> options, the working group can also choose to propose deprecation of >>> such >>> algorithms. Such deprecation needs to be done with care, ensuring that >>> interoperability and the needs of existing implementers and >>> deployments are >>> properly considered. Where deprecation is practical, the working >>> group is >>> encouraged to deprecate. >>> >>> Arguing about what is outdated always takes a long time. "It's still >>> good enough for the next five years." "No one ever changes their >>> software so we need to do this early." "We have people who need to use >>> this for another ten years and they understand the consequences." "We >>> can ignore this small set of users." "We cannot ignore this small set of >>> users." "We got rid of that algorithm in TLS and it didn't hurt." "Our >>> users are different than web browser users." "The charter says we must >>> do this 'with care' and you are being careless." "No, you're just being >>> stubborn." >> >> We would have that argument again yes. Maybe we'd get better at >> handling it if we do it in a more concentrated fashion? I'm not >> sure we would, but I figure it may be worth trying, esp as I'd >> bet that we do find things we'd want to deprecate. > > We haven't gotten any better in the past 15 years of experience with > that. I'm willing to bet we're doing our best now, and that our best > includes thrashing about this topic every time it comes up. > >>> Without that paragraph in the charter, I'm pretty sure consensus will be >>> easy. >> >> Do you mean consensus on the charter? (I think you do, just checking) > > Yes. > > --Paul Hoffman > From nobody Wed Nov 18 15:33:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBD91B33DB for ; Wed, 18 Nov 2015 15:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgiBlG7cNtUK for ; Wed, 18 Nov 2015 15:33:39 -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 7532F1B33C6 for ; Wed, 18 Nov 2015 15:33:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4AAD3BE3E; Wed, 18 Nov 2015 23:33:38 +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 LBG0_D9Rg7aM; Wed, 18 Nov 2015 23:33:37 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3DC9ABE33; Wed, 18 Nov 2015 23:33:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447889617; bh=vQt0Jd3u8ousiNpraN+ZvRl7utLbriCiFmfJIZ8mG2c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=oJh8YeaWaj90UQo5mWFLTdu4/jTthIY4gKmtGYYCj10PApAyICoBOyRb7qq7tQPdF Xjom1Bx6UYtGzfY5Sb6bnlcQ60LD8kyu14oOJyfXwkb6ga/qh1BoO6Wf7P3dJl4kUk U+z4eJ7s0OsuQ6TDSi35kfg7oVq7GXrPLskOGAvM= To: Russ Housley , IETF SAAG References: <564C5FCC.8080107@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564D0ACE.6050406@cs.tcd.ie> Date: Wed, 18 Nov 2015 23:33:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 23:33:41 -0000 On 18/11/15 19:58, Russ Housley wrote: > Good point. Maybe this group should only tackle the registries and > the conventions for using existing protocol fields. If a change to > the protocol is needed, maybe that should go to a separate protocol > maintenance group. I agree there's a line that could be crossed here, but I think the charter as written describes that well enough and doesn't cross that line. If there's better wording though, happy to make changes that make that clearer. I'm not sure if "not modifying existing PDUs" or similar language would be that much clearer but maybe it would. (OLD/NEW text welcome.) Cheers, S. From nobody Wed Nov 18 15:35:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE321B33DC for ; Wed, 18 Nov 2015 15:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0N8SUflEQiq for ; Wed, 18 Nov 2015 15:35:42 -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 AC8C31B3403 for ; Wed, 18 Nov 2015 15:35:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 586D8BE3E; Wed, 18 Nov 2015 23:35:41 +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 PraiMXHVl953; Wed, 18 Nov 2015 23:35:40 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BDC75BE33; Wed, 18 Nov 2015 23:35:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447889740; bh=AYAc2fC/IFu9p6dG7coemvVWg32VfO6MYm2bUrPm1XI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Uw+1E4fqxZREfihPzGXPCuIYTHIdykf8hzUZvDEWOoVku3qcCIQx3B8pr4dquGaTs lnub55vhaV+rpz7s1cOJRRE5nPBl0DXDUOUCuM6qLmpmbGzaxdbpewT66IjPYiZ1Ss 1lT2Q3lmacRoU+LDtkfKrBRTwJOEtENj6OqqH/vQ= To: John Mattsson , Simon Josefsson , Paul Hoffman References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> <87twoj13uy.fsf@latte.josefsson.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564D0B3D.90405@cs.tcd.ie> Date: Wed, 18 Nov 2015 23:35:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 23:35:44 -0000 On 18/11/15 20:12, John Mattsson wrote: > Simon said: >> >I suppose the intention is to deprecate "obviously bad" algorithms like >> >rc2, rc4, md2, md4, md5, collision-resistant uses of sha1, single-des, >> >small block (<128b) size block ciphers, <=1024 bit DSA/RSA/DH, <224bit >> >ECC, etc, should we realize any of these examples when going through >> >protocols. Borderline cases may include HMAC-MD5 and 224-bit ECC. > +1 (But add two-key tripple-des and change to <2048 bit DSA/RSA/DH). I think the above characterises the deprecation stuff well. This part of the work is meant to tidy up and not be revolutionary:-) S. From nobody Wed Nov 18 15:43:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28611B3907 for ; Wed, 18 Nov 2015 15:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=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 wgprZk25QBsM for ; Wed, 18 Nov 2015 15:43:11 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 967611B390A for ; Wed, 18 Nov 2015 15:43:11 -0800 (PST) Received: by qgad10 with SMTP id d10so40741608qga.3 for ; Wed, 18 Nov 2015 15:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=loMs9Iog91bXPzbqF+GBF1gWKcLTLHqU4j291o7I9b0=; b=D5WR0Fq85g1AnxB/Ji7uzGQbnuhBqzesva6flykuqGEavjlg+aman+J4ZHXM26RM7c wioI3aJZRcFdwiY2rFcsHO2J59b3jkWUMYZO6cyjx1w/hNGsAuehB0beteaVfYWuvAnD T/KptmTGhutZm5dG2AizNYXjN+B737KC9HTlFVqaXy/0wApQ4moatYWRpQQyvczM/wUp 0ZUcQGHkcIxyguykvqLmaSyMSvtZraIIzgKdefaENmY/6ZGhTXNIW9FvA/annAadGn6J JEKVjiiagetfci098hM4O/fK8AHxay6fOD0aitxtDBR3NvjAz8Eio1nF9uml/FPGrklU dk2g== X-Received: by 10.140.236.14 with SMTP id h14mr4400625qhc.7.1447890190747; Wed, 18 Nov 2015 15:43:10 -0800 (PST) Received: from [172.20.3.0] ([65.200.157.66]) by smtp.gmail.com with ESMTPSA id 89sm1624003qgz.7.2015.11.18.15.43.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Nov 2015 15:43:09 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <564D09CE.9030808@cs.tcd.ie> Date: Wed, 18 Nov 2015 18:43:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> <564D09CE.9030808@cs.tcd.ie> To: Stephen Farrell Archived-At: Cc: Paul Hoffman , "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 23:43:13 -0000 Sent from my iPhone > On Nov 18, 2015, at 6:29 PM, Stephen Farrell w= rote: >=20 >=20 >=20 >> On 18/11/15 18:35, Paul Hoffman wrote: >>> On 18 Nov 2015, at 9:03, Stephen Farrell wrote: >>>=20 >>>> On 18/11/15 16:48, Paul Hoffman wrote: >>>> How can this WG be "short-lived" when you have the following in the >>>> charter? >>>=20 >>> My assumption (possibly wrong) was that the curdle wg would do >>> the work on adding things and if, whilst doing that, they find >>> stuff that can be deprecated, then they can choose to go do the >>> work to deprecate stuff. But that the plan is to close when the >>> new stuff is done. >>=20 >> If that's the plan, it should be stated in the charter. >=20 > I agree, but thought it was stated there already. Can you send > OLD/NEW text to help? >=20 >> Some people in >> our community really like to focus on deprecating outdated algorithms >> and garnering publicity for shaming those who continue to use them. >>=20 >> A different thought is to have two WGs: curdle for "add new EC" and >> depoldalg for "deprecating old algorithms". The latter could be given a >> one-year charter. >=20 > Meh. Frankly I doubt that there'd be willing workers for such a > deprecating-only WG, I reckon it'd be far too likely to languish > not at the top of anyone's todo list. I'd argue to see what happens > with curdle and then maybe revisit if nobody has the energy to > deprecate anything in that context we can revisit the issue. >=20 > But I could be wrong of course. If folks want to write drafts that > deprecate things and if there're enough of those queued up I'd be > very happy to help start a wg on that topic. So far though, such > drafts are fairly rare. I agree. We can see what happens and the energy level for each first. Thanks, Kathleen=20 >=20 > And to save scrolling, post-quantum stuff is a topic for cfrg and > not (yet) the IETF as far as I'm concerned. >=20 > So I hope we're ok with the (to me anyway) simpler plan of enabling > the work that folks clearly want to get done and also leaving space > for deprecating stuff as and when people are feeling the love for a > bit of deprecatiion. >=20 > Cheers, > S. >=20 >>=20 >>> My intent fwiw was not that this wg hang around for ever figuring >>> out what to deprecate next. >>=20 >> With the NSA's newly-stated belief that 2048-bit RSA/DH is not good >> enough for protection against post-quantum crypto (I'm purposely not >> giving my opinion on any part of that statement...), you probably need >> to be firmer in stating what is out of scope for deprecation. >>=20 >>> Does that help? If so, figuring out how to say it better would >>> be an improvement. (Any suggestions?) >>=20 >> See above. There might even be a third "depalgforpqc" WG. >>=20 >>>> As the CURDLE working group will be handling changes to protocols and >>>> registries some of which include what are now considered outdated >>>> algorithm >>>> options, the working group can also choose to propose deprecation of >>>> such >>>> algorithms. Such deprecation needs to be done with care, ensuring that= >>>> interoperability and the needs of existing implementers and >>>> deployments are >>>> properly considered. Where deprecation is practical, the working >>>> group is >>>> encouraged to deprecate. >>>>=20 >>>> Arguing about what is outdated always takes a long time. "It's still >>>> good enough for the next five years." "No one ever changes their >>>> software so we need to do this early." "We have people who need to use >>>> this for another ten years and they understand the consequences." "We >>>> can ignore this small set of users." "We cannot ignore this small set o= f >>>> users." "We got rid of that algorithm in TLS and it didn't hurt." "Our >>>> users are different than web browser users." "The charter says we must >>>> do this 'with care' and you are being careless." "No, you're just being= >>>> stubborn." >>>=20 >>> We would have that argument again yes. Maybe we'd get better at >>> handling it if we do it in a more concentrated fashion? I'm not >>> sure we would, but I figure it may be worth trying, esp as I'd >>> bet that we do find things we'd want to deprecate. >>=20 >> We haven't gotten any better in the past 15 years of experience with >> that. I'm willing to bet we're doing our best now, and that our best >> includes thrashing about this topic every time it comes up. >>=20 >>>> Without that paragraph in the charter, I'm pretty sure consensus will b= e >>>> easy. >>>=20 >>> Do you mean consensus on the charter? (I think you do, just checking) >>=20 >> Yes. >>=20 >> --Paul Hoffman >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Nov 18 15:57:09 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55E1B3962 for ; Wed, 18 Nov 2015 15:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNrtAMWPsc-Q for ; Wed, 18 Nov 2015 15:57:06 -0800 (PST) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75E61B395F for ; Wed, 18 Nov 2015 15:57:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id DA72AE66B; Wed, 18 Nov 2015 18:57:04 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOhdU2hDV-1h; Wed, 18 Nov 2015 18:57:04 -0500 (EST) Received: from [192.168.1.180] (wsip-174-76-19-88.oc.oc.cox.net [174.76.19.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 0A06AE40F; Wed, 18 Nov 2015 18:57:03 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <564D0B3D.90405@cs.tcd.ie> Date: Wed, 18 Nov 2015 15:57:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <88F171C9-0D70-45F4-8573-253FB305B5D3@oxy.edu> References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> <87twoj13uy.fsf@latte.josefsson.org> <564D0B3D.90405@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 23:57:07 -0000 FWIW I=E2=80=99m in favor of only one WG, and I would hope that people = would feel the need to depreciate algorithms at the same time they add = new ones. I stop short of wanting the symmetry in the charter since I = think there are probably a lot of situations where you may want to = add/deprecate different numbers of algorithms. > On Nov 18, 2015, at 3:35 PM, Stephen Farrell = wrote: >=20 > On 18/11/15 20:12, John Mattsson wrote: >> Simon said: >>>> I suppose the intention is to deprecate "obviously bad" algorithms = like >>>> rc2, rc4, md2, md4, md5, collision-resistant uses of sha1, = single-des, >>>> small block (<128b) size block ciphers, <=3D1024 bit DSA/RSA/DH, = <224bit >>>> ECC, etc, should we realize any of these examples when going = through >>>> protocols. Borderline cases may include HMAC-MD5 and 224-bit ECC. >> +1 (But add two-key tripple-des and change to <2048 bit DSA/RSA/DH). >=20 > I think the above characterises the deprecation stuff well. This part > of the work is meant to tidy up and not be revolutionary:-) >=20 > S. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag Personal: hbhotz@oxy.edu Business: hhotz@securechannels.com From nobody Wed Nov 18 17:19:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5F61B32D7 for ; Wed, 18 Nov 2015 17:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8E-um9Ktony for ; Wed, 18 Nov 2015 17:19:04 -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 A956E1A0029 for ; Wed, 18 Nov 2015 17:19:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 93D51BE55 for ; Thu, 19 Nov 2015 01:18:59 +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 uH57rgFfPa7T for ; Thu, 19 Nov 2015 01:18:57 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A0EE7BE53 for ; Thu, 19 Nov 2015 01:18:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447895937; bh=fJdHeW/sXxa9v7U193dfT2TJ92mYY/Xa3HyVP1UUQJg=; h=Subject:References:To:From:Date:In-Reply-To:From; b=Oqu33VDZGg8h8UobbHvVZfAOiLCKLEStA16payeXj/pp3er9cZ6uoSHOHmHdlOYCZ Mw0vWXJhizeyrmkHVGu1Vzlu7dxgDQ8XQ0XkkUf6D6aRKZqMG+pxaE9H3mSj1Y3VnO XZ90nnA5E0rs7UBrkpe9MMo6krJBEcPTVWegaE1s= References: <20151119011248.EF374180005@rfc-editor.org> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20151119011248.EF374180005@rfc-editor.org> Message-ID: <564D2380.80403@cs.tcd.ie> Date: Thu, 19 Nov 2015 01:18:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151119011248.EF374180005@rfc-editor.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: BCP 201, RFC 7696 on Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 01:19:08 -0000 This was discussed on here, so here's the RFC/BCP numbers... Cheers and thanks for the good discussion on this one, S. -------- Forwarded Message -------- Subject: BCP 201, RFC 7696 on Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms Date: Wed, 18 Nov 2015 17:12:48 -0800 (PST) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. BCP 201 RFC 7696 Title: Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms Author: R. Housley Status: Best Current Practice Stream: IETF Date: November 2015 Mailbox: housley@vigilsec.com Pages: 19 Characters: 50543 See Also: BCP 201 I-D Tag: draft-iab-crypto-alg-agility-08.txt URL: https://www.rfc-editor.org/info/rfc7696 DOI: http://dx.doi.org/10.17487/RFC7696 Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory- to-implement algorithm suite to another over time. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Nov 18 17:40:33 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B311B3B0A for ; Wed, 18 Nov 2015 17:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPC65VBLGrG6 for ; Wed, 18 Nov 2015 17:40:31 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647F71B3B09 for ; Wed, 18 Nov 2015 17:40:31 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 85E8928494E; Thu, 19 Nov 2015 01:40:30 +0000 (UTC) Date: Thu, 19 Nov 2015 01:40:30 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20151119014030.GF18315@mournblade.imrryr.org> References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 01:40:32 -0000 On Wed, Nov 18, 2015 at 10:35:42AM -0800, Paul Hoffman wrote: > A different thought is to have two WGs: curdle for "add new EC" and > depoldalg for "deprecating old algorithms". The latter could be given a > one-year charter. I don't think that's a good idea. It is good to have some balance to avoid a WG that just stacked with die-hard deprecators. Too much deprecationt too fast can be counter-productive. In any case there have to be realistic alternatives, and I think a single group can be better focused on how to improve security than just where to slash and burn. -- Viktor. From nobody Wed Nov 18 21:16:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999C11A87D9 for ; Wed, 18 Nov 2015 21:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D30PFqK2oB2w for ; Wed, 18 Nov 2015 21:16:33 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9B01A87DB for ; Wed, 18 Nov 2015 21:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447910193; x=1479446193; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=diHs2QDHvYmdNqZ8SmDSuPGmnBFXkhPhj/hmAlgFXC4=; b=vmrA/kpjdZPag/IuCg6pcHsxIBQF05Dq7V2rxKHesmRBeR7jVRYHZkM9 aQxDLgMRMMWooSqKLLsYvNw3YIMa3aIjCEROJGx3l/0xK3qEyMbinhrJM DtyeZq9TmK7DYSBD6qj/JWjLs+HZpTDYFLjK85e8CP2SOduTRBYW40eEr DQxPKw9iT4j1uH04hQgHRL1AVkTfdyZWuC/zQFJSOwyH2m+XhLZ0X/ex7 Z/MjhnjTq3yS529YfwRCDn/hiMbqcNooquIlghID3/Xfa7tNoccI6yfK6 L72ULa3GuvSm/5YjaNWZC2QG1EOZX2lZvu3onm7gqpphAXQOMlYtItNFF g==; X-IronPort-AV: E=Sophos;i="5.20,316,1444647600"; d="scan'208";a="54940823" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2015 18:16:30 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Thu, 19 Nov 2015 18:16:31 +1300 From: Peter Gutmann To: Simon Josefsson , Paul Hoffman Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIfOolpipP2MZvkGbJ40Yn5ajpZ6iAlrv//8/rACAAO/Xs4AAnOSL Date: Thu, 19 Nov 2015 05:16:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B69396@uxcn10-5.UoA.auckland.ac.nz> References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org>, <87twoj13uy.fsf@latte.josefsson.org> In-Reply-To: <87twoj13uy.fsf@latte.josefsson.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 05:16:35 -0000 Simon Josefsson writes:=0A= =0A= >I don't believe recommending against 2048-bit RSA/DH will do any good.=0A= >It will slow adoption of decent crypto where weak crypto is deployed.=0A= =0A= +1. There are still organisations struggling to upgrade to 1024-bit=0A= (from 512-bit), giving them a totally unreachable goal beyond that =0A= will just make them feel better about ignoring it.=0A= =0A= Another thing about 2048 bit is that asymmetric isn't symmetric,=0A= you don't double its strength every time you add another bit, so=0A= there's no need to progress by doubling the bit size, all that does=0A= is vastly increase the amount of work required. There's little=0A= actual practical security difference between a 1536-bit key and a =0A= 2048-bit one, while there's a large difference in the amount of=0A= CPU power required.=0A= =0A= Peter.=0A= From nobody Thu Nov 19 00:01:37 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7BE1AC3E1 for ; Thu, 19 Nov 2015 00:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKpznLjufV39 for ; Thu, 19 Nov 2015 00:00:29 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910491AC3E0 for ; Thu, 19 Nov 2015 00:00:28 -0800 (PST) X-AuditID: c1b4fb2d-f79626d000004282-1a-564d819abfd1 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.0A.17026.A918D465; Thu, 19 Nov 2015 09:00:26 +0100 (CET) Received: from ESESSMB310.ericsson.se ([169.254.10.15]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 09:00:26 +0100 From: John Mattsson To: Peter Gutmann , Simon Josefsson , Paul Hoffman Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIiMUyxwHZkFPGkGCMx9vxuLjV56iCtIAgAAmk0WAAIx2AIAAPpCA Date: Thu, 19 Nov 2015 08:00:26 +0000 Message-ID: References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> <87twoj13uy.fsf@latte.josefsson.org> <9A043F3CF02CD34C8E74AC1594475C73F4B69396@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B69396@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-ID: <7AE02239D3A11647A36788C0933A885D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7uu6sRt8wgxft6ha31n9htXj57jmr xZT+TiaLe1susTuweFxsPMDksWTJTyaPmWcusnt8nn2VOYAlissmJTUnsyy1SN8ugSvj0bpz jAWrBCtu/NjN3sD4QaCLkZNDQsBEYtv+TlYIW0ziwr31bF2MXBxCAocZJY6e/ccK4SxhlLh2 9yJYFZuAgcTcPQ1sILaIQI3EqpYdjCA2s4CyxNs/T5hAbGGgmo1LtzFB1BhKHNy1nxnCdpP4 dvcKmM0ioCrx5sAXsJm8AuYSry4fY4RYNpNJYtX240DNHBycAsESuw5xgtQwAl33/dQaJohd 4hK3nsxngrhaQGLJnvPMELaoxMvHIEdzcIgK6EnsWS4JEVaSaFzyBCzMLKApsX6XPsQUa4mb q59ATVSUmNL9kB3iGkGJkzOfsExglJiFZNkshO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0I2O9 1KLM5OLi/Dy9vNSSTYzAWD245bfuDsbVrx0PMQpwMCrx8H5g8g0TYk0sK67MPcQowcGsJML7 oAwoxJuSWFmVWpQfX1Sak1p8iFGag0VJnLeF6UGokEB6YklqdmpqQWoRTJaJg1OqgbGrfG+E yAWfVv0FgmefdFy3ir3X1/+g8OJtkdYS6V1rj+06J9H75LZBiJLInKqDkyeahh5wsg3/M2uR UzajCK/6isB7i6Vdr7XNM7nz1Ei4PfpL52XfJLnLMsYmtSf4r7RUKSbusWvokPvTefVP4d3i vVHvFZgdD7npN8g8usKzLi6ycYdgixJLcUaioRZzUXEiAG2IY6TRAgAA Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 08:00:31 -0000 DQpPbiAxOS8xMS8xNSAwNjoxNiwgInNhYWcgb24gYmVoYWxmIG9mIFBldGVyIEd1dG1hbm4iDQo8 c2FhZy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFj Lm56PiB3cm90ZToNCg0KPlNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9zZWZzc29uLm9yZz4gd3Jp dGVzOg0KPg0KPj5JIGRvbid0IGJlbGlldmUgcmVjb21tZW5kaW5nIGFnYWluc3QgMjA0OC1iaXQg UlNBL0RIIHdpbGwgZG8gYW55IGdvb2QuDQo+Pkl0IHdpbGwgc2xvdyBhZG9wdGlvbiBvZiBkZWNl bnQgY3J5cHRvIHdoZXJlIHdlYWsgY3J5cHRvIGlzIGRlcGxveWVkLg0KPg0KPisxLiAgVGhlcmUg YXJlIHN0aWxsIG9yZ2FuaXNhdGlvbnMgc3RydWdnbGluZyB0byB1cGdyYWRlIHRvIDEwMjQtYml0 DQo+KGZyb20gNTEyLWJpdCksIGdpdmluZyB0aGVtIGEgdG90YWxseSB1bnJlYWNoYWJsZSBnb2Fs IGJleW9uZCB0aGF0DQo+d2lsbCBqdXN0IG1ha2UgdGhlbSBmZWVsIGJldHRlciBhYm91dCBpZ25v cmluZyBpdC4NCg0KSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCByZWNvbW1lbmQgYWdhaW5zdCAy MDQ4LWJpdCBSU0EvREggYXQgYWxsLCBidXQgbXkNCmV4cGVyaWVuY2UgaXMgdGhlIGNvbXBsZXRl IG9wcG9zaXRlLCB1bmxlc3MgeW91IHN0YXRlIE1VU1QgTk9ULCBzb21lDQpwZW9wbGUgdGVuZCB0 byB0aGluayB0aGVyZSBpcyBubyBwYW5pYy4gVG8gdGhlbSBTSE9VTEQgTk9UIGluZGljYXRlIHRo YXQNCnVzYWdlIGlzIGFjY2VwdGFibGUgZm9yIGEgd2hpbGUgbG9uZ2VyIGFuZCB0aGF0IHRoZXkg Y2FuIHNwZW5kIGRldmVsb3BtZW50DQptb25leSBvbiBzb21ldGhpbmcgZWxzZS4NCg0KPkFub3Ro ZXIgdGhpbmcgYWJvdXQgMjA0OCBiaXQgaXMgdGhhdCBhc3ltbWV0cmljIGlzbid0IHN5bW1ldHJp YywNCj55b3UgZG9uJ3QgZG91YmxlIGl0cyBzdHJlbmd0aCBldmVyeSB0aW1lIHlvdSBhZGQgYW5v dGhlciBiaXQsIHNvDQo+dGhlcmUncyBubyBuZWVkIHRvIHByb2dyZXNzIGJ5IGRvdWJsaW5nIHRo ZSBiaXQgc2l6ZSwgYWxsIHRoYXQgZG9lcw0KPmlzIHZhc3RseSBpbmNyZWFzZSB0aGUgYW1vdW50 IG9mIHdvcmsgcmVxdWlyZWQuICBUaGVyZSdzIGxpdHRsZQ0KPmFjdHVhbCBwcmFjdGljYWwgc2Vj dXJpdHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgMTUzNi1iaXQga2V5IGFuZCBhDQo+MjA0OC1iaXQg b25lLCB3aGlsZSB0aGVyZSdzIGEgbGFyZ2UgZGlmZmVyZW5jZSBpbiB0aGUgYW1vdW50IG9mDQo+ Q1BVIHBvd2VyIHJlcXVpcmVkLg0KDQpBdCBsZWFzdCByZWdhcmRpbmcgREggKGFuZCBzaWduYXR1 cmVzKSwgc29tZWJvZHkgdmVyeSBjb25jZXJuZWQgd2l0aCBDUFUNCmN5Y2xlcyBzaG91bGQgbWln cmF0ZSB0byBFQ0MgbG9uZyB0ZXJtLiBUaGUgcHJhY3RpY2FsIHNlY3VyaXR5IGRpZmZlcmVuY2Vz DQpiZXR3ZWVuIERIIHdpdGggMTAyNCBNT0RQIGFuZCBjdXJ2ZTI1NTE5IGlzIGh1Z2UsIGFuZCB0 aGVyZSBpcyBhIGxhcmdlDQpkaWZmZXJlbmNlIGluIHRoZSBhbW91bnQgb2YgQ1BVIHBvd2VyIHJl cXVpcmVkIChjdXJ2ZTI1NTE5IGlzIG11Y2gNCmZhc3RlcikuIGh0dHA6Ly9iZW5jaC5jci55cC50 by9wcmltaXRpdmVzLWRoLmh0bWwNCg0K From nobody Thu Nov 19 06:07:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661001B29FF for ; Thu, 19 Nov 2015 06:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=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 7WF09dnnNSva for ; Thu, 19 Nov 2015 06:07:11 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 1C3CF1B2A04 for ; Thu, 19 Nov 2015 06:07:10 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tAJE6ko8004099 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 19 Nov 2015 15:06:47 +0100 From: Simon Josefsson To: Yoav Nir References: <564C5FCC.8080107@cs.tcd.ie> <8BAFE0B6-3793-4F20-A32F-4778CF19CC53@gmail.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151119:saag@ietf.org::EQIJsjzm65nI7Q0b:0Al+ X-Hashcash: 1:22:151119:ynir.ietf@gmail.com::fqaAgyYFqTm3z+gZ:4+VH X-Hashcash: 1:22:151119:stephen.farrell@cs.tcd.ie::E62rpfAIAtD46Bhe:7Uc/ Date: Thu, 19 Nov 2015 15:06:45 +0100 In-Reply-To: <8BAFE0B6-3793-4F20-A32F-4778CF19CC53@gmail.com> (Yoav Nir's message of "Thu, 19 Nov 2015 00:27:50 +0200") Message-ID: <87d1v613t6.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 14:07:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir writes: > So speaking only for the deprecate part, I=E2=80=99m wondering if it shou= ld be > in-scope to scour IANA registries looking for obscure algorithms to > deprecate. I believe that activity would be useful, but with limited overlap with the activity of introducing new mechanisms. That said, if we are only forming one WG around these topics, I prefer to have deprecation in scope of that WG rather than removing that part of the charter. > Looking at the TLS and IPsec registries I can find RC5, IDEA, CAST, > Blowfish, Tiger, and of course some national ciphers such as camellia, > ARIA, SEED, and GOST. I=E2=80=99m pretty sure we don=E2=80=99t want to go= there with > the national ciphers, but deprecating a bunch of the others that are > rarely if ever in use seems like a good idea. I believe the IETF's position should be to describe and encourage an upgrade-path for algorithms that doesn't meet a reasonable technical design criteria. Some of the ciphers in your list fail reasonable requirements (e.g., having >=3D128-bit block size for block ciphers) and should therefor be actively recommended against. Further, I don't see any example in your list that would be a defendable technical choice for a new protocol today. If that is the case, we should actively recommend against prolonged use of the algorithm, and specify and recommend an upgrade path. It is not like it is ever going to be a good technical idea to start to use ARIA/SEED/GOST if you aren't forced to use it or is using it today. /Simon > Yoav > >> On 18 Nov 2015, at 1:23 PM, Stephen Farrell = wrote: >>=20 >>=20 >> Hiya, >>=20 >> Following on from the earlier discussion about adding curves >> etc. a few folks (*) helped Kathleen and I craft an initial cut >> at charter text. [1] >>=20 >> I think we have people (well, mostly Simon:-) to do the editing >> work for this. >>=20 >> If you'd be willing to be a chair, please send an offlist mail >> to Kathleen and I. >>=20 >> If you think this is useful and would review documents please >> respond to this mail saying so. I'd like to see that we have >> enough folks interested to make this work. >>=20 >> If you have changes to charter text to suggest please do so, >> preferably in OLD/NEW form. >>=20 >> If you think this is a bad idea, I'm sure you'll not be shy in >> saying so too:-) >>=20 >> If there's not enough interest or if there're sound objections then >> we can abandon the idea and fall back to processing this stuff more >> slowly and more ad-hoc as AD sponsored drafts. (The main point of >> curdle is to be more organised and hopefully quicker at this.) >>=20 >> Thanks, >> S. >>=20 >> [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ >>=20 >> (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and >> Sean Turner for help with the text. The fault however is mine, >> if it's bad text or a dumb idea:-) >>=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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWTdd1AAoJEIYLf7sy+BGdz4IIAJOM9oSZwHG/hyZ6uV5lwOan 8SQUh8gG//QEurVwQGFWV47cJ6Cqrt1Q37BCY/Nvrh48s4QpHUH6LH8vwm4J6+KV KNBeecXW8xATyNjUICqE07cwUqg0jIprjoQtHK6+bWQ1xSflrZp5ELIOtfKXQY+z kvbBXA1NpEf2hfGYJ8VwvnqL8n8s1XuU6JuWZ2MJuAIyZsYkxX6QQ06k7zeXHNCw +tcJwGwntF8v2AXp1ewdMPs7sKm91SQXK1SmDh4ptUDz+b2POzwXAEJrmEKmdxGJ yp3gkaTycbG3CpQJzgEo5PxsOfgCBW8+RC850oH8DAQBUIi3CqIlo9hZzIn3Yek= =iJ0e -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 19 06:55:00 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46D21A893A for ; Wed, 18 Nov 2015 22:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.136 X-Spam-Level: X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw_dmbleQKIZ for ; Wed, 18 Nov 2015 22:12:50 -0800 (PST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A121A8938 for ; Wed, 18 Nov 2015 22:12:50 -0800 (PST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DA5C74002D; Thu, 19 Nov 2015 07:12:47 +0100 (CET) Received: from armitage.lysator.liu.se (armitage.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) by mail.lysator.liu.se (Postfix) with SMTP id E7F424000A; Thu, 19 Nov 2015 07:12:45 +0100 (CET) Received: by armitage.lysator.liu.se (sSMTP sendmail emulation); Thu, 19 Nov 2015 07:12:45 +0100 From: nisse@lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) To: "Mark D. Baushke" References: <564C5FCC.8080107@cs.tcd.ie> <89505.1447867474@eng-mail01.juniper.net> Date: Thu, 19 Nov 2015 07:12:45 +0100 In-Reply-To: <89505.1447867474@eng-mail01.juniper.net> (Mark D. Baushke's message of "Wed, 18 Nov 2015 09:24:34 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: X-Mailman-Approved-At: Thu, 19 Nov 2015 06:54:59 -0800 Cc: ietf-ssh@NetBSD.org, "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 06:12:52 -0000 "Mark D. Baushke" writes: > Given that current implementatons of this informational RFC are using > AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track > Cipher algorithms use lowercase with '-' as word separators, I would > suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and > that they should NOT be added to the MAC Algorithms Names in IANA. THe openssh way of ignoring the mac negotiation completely, if an aead cipher is negotiated, seems nice and simple. How does it interact with first_kex_packet_follows logic, does that need any clarification (a simple rule is to say that if both sides advertise the same aead cipher as the first cipher, then for first_kex_packet_follows purposes, the mac negotiation is considered successful and correctly guessed)? Not sure if it has a place in the same rfc, but I think a proper specification for use aead is quite inportant. Regards, /niels --=20 Niels M=C3=B6ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Thu Nov 19 08:59:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E4D1B2CBD for ; Thu, 19 Nov 2015 08:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GGPLQ5dxdh6 for ; Thu, 19 Nov 2015 08:59:46 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF2F1B2CB9 for ; Thu, 19 Nov 2015 08:59:46 -0800 (PST) Received: from BLUPR05CA0046.namprd05.prod.outlook.com (10.141.20.16) by BN3PR0501MB1378.namprd05.prod.outlook.com (10.160.117.12) with Microsoft SMTP Server (TLS) id 15.1.331.20; Thu, 19 Nov 2015 16:59:44 +0000 Received: from BN1AFFO11FD022.protection.gbl (2a01:111:f400:7c10::152) by BLUPR05CA0046.outlook.office365.com (2a01:111:e400:855::16) with Microsoft SMTP Server (TLS) id 15.1.331.20 via Frontend Transport; Thu, 19 Nov 2015 16:59:44 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.17) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.17 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.17) by BN1AFFO11FD022.mail.protection.outlook.com (10.58.52.82) with Microsoft SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Thu, 19 Nov 2015 16:59:43 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 19 Nov 2015 08:59:42 -0800 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id tAJGxcD18982; Thu, 19 Nov 2015 08:59:39 -0800 (PST) (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 53A021144F; Thu, 19 Nov 2015 08:59:38 -0800 (PST) To: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6ller=3F=3D?= In-Reply-To: References: <564C5FCC.8080107@cs.tcd.ie> <89505.1447867474@eng-mail01.juniper.net> Comments: In-reply-to: Niels =?us-ascii?Q?=3D=3Futf-8=3FQ=3FM=3DC3=3DB6lle?= =?us-ascii?Q?r=3F=3D?= message dated "Thu, 19 Nov 2015 07:12:45 +0100." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2015 08:59:38 -0800 Message-ID: <89694.1447952378@eng-mail01.juniper.net> Sender: X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD022; 1:Ox0+zLqd/g7Gf3fM8BZthc7BT3xbpZGbLsnC9ENHiH74ZZiAFPSjP5no+9c+jPlBKshclkEp+6h8sv/tr+z8JUEjQJHvSJ5kQNIH3LGV0zMX77gLYiezGQAXIuSGDP/2+3C0EXxqYhQlg7PyEZAhVVzKgK+J9k22DPKcEBcp327UZI+w3LlEig80uQTbKIZcqpeBNNXfkKl9eYU/osGwIh2loeZvRdseGOJzI9kL+H5WJRcP1ZtECUTW/AAsUgqXsy54hGRd5+o5mdUtmd14eJGd9l8CgiBP8NjrEQwQlwU0RVIl3aAwOx01e0XRZsCzG7RReI7+WVy9Au9mGgT/5vrCf5BJa3TWZ3+9IZN2oTFdCOxjKjQh905MYHo291K7JopkGdIa/3HBA26gvjZQ5ak4RkZoLkr4EPBcCkiyVjQ= X-Forefront-Antispam-Report: CIP:66.129.239.17; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(199003)(189002)(164054003)(2950100001)(19580395003)(6806005)(19580405001)(5001960100002)(76176999)(106466001)(50986999)(117636001)(54356999)(92566002)(110136002)(86362001)(53416004)(105596002)(47776003)(189998001)(87936001)(76506005)(586003)(23676002)(5003600100002)(11100500001)(97736004)(77096005)(81156007)(50466002)(69596002)(5007970100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1378; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1378; 2:vrQjLkNYG0aOji9vcHvB15XFmBgoq5+yT3V6uvS+f226I1yCbmALNZjl0Zmm++q1RyinNJl0BFYX1vSETg0ZKiQFBX/xDiyyZtS2mLagZC2CxgK2RhdxZBQ3GpgwvB0Xyf9wo+jLBn+wU2uVkVQUsA==; 3:WUx5FNu+XDGkiOage1QjfMBihXSMgnRXrmYDGrz37lNtZ87poebSb5b/CU0DLmsa8S8PVNv4ZwsWl6s8qN0n6LTPEHOAnjyWWo0IRUV8Y0gJq4HgenVuV/8e+KoPd99+bwYH86eUHNBt7iqGPs6ghAz5SJimJ4RmTuYGIDsihgLGR6d/mF4liH0/16HWao3lUoMPm9+jozTBWht2N+AiOQQG4VSy/2v/eK0dljhLZpc=; 25:5xA3BARHg7TQDyGzhQR55V+TKj/6HB51VLycvroXUan8AYe+xsNh/lY08KIGUi4vz+gBdsfPrJFoC3yQ3OCXHwLzWBUD5JmxWsrqkL4ZZYRsDFOdTKCXp7a850+jdyW68rG0snUOQtn/0je88gLzH1il9IDZM6h0oi8QzYL2dlmblrh/F5T/b4aKM6W1jWldwqTpCKfO5pnaV6PWH5hTaT5WHBBypkdOONKWIbCMSOArwERqipFJL0xoSbxcpcSIwLz6PIwA726t1j1Hxa6kyA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1378; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1378; 20:m41o9RoGt921dy8UCSUybpW6qUG9Kp5+WucGhwvK/jV3iFotaMXqchJLE3X10wr8yS5+aeQ8UKNErH6m+/gWfF53NVGiBu/NImfLSeZmPUo64zeu/o8jkmmwfnekFYWkgrCEQwwyqsmtnQYMJlVBWwewwU4JkYvW/MZn5hPcsHdbEZjLLvQoTaYV+FdsTnayomnMHgzChpGpM+yJ2BW0l7BYNXGSGmWf1PlwEXdVMscrHBGZH5j0H5Afg9375l2xYoRolMXb5s5P9M95/aMowm5MgK/938jvWdLPfgvhVGn9WnBZZIwviKNVLFZ+c6fsPLN1pGP81Lt05/zbCdCqOR/e8hOQbGacO/yMhUXdDGrZAbd5ib4FyO1svcQ655t80PYrl3E9CORrGfPIJyew+NdIKHaQSEvlYRr62VnRE0DqmrBWz4X9wkC2qHCr8q6z6Gniy1DjeeCAl9BW7t+WB30uwhzhkJinH/k9Uf8FeX8ZWwW2ZAcScgZOEFlWRWWr; 4:AyUOwhjIlyo8w3d9Yz1QPkWENkwzfniXqzL2+lOckz1fSh6rLwfYl2GqbW5ev8KITEAbONTyp4h2aPek68VbT9OW4TQRJnUbKdDhh6OEeYaFVz1gYEHiBpYqy8hK9RSXdrIarxW1m0of3UKG9UK8m4wnDjmhEBgsro+M11w1f8uviWpfCw228UKONWiTA3x44WcFimasdLtjy3NNVrmOtsZAlIw7HxAyMEkHaJpUD3PsFz0I1hKKtnRPoxuyu/NeyCxurgzxTnBVEATbtfuDCHZaM3pDw59u8WQZcy9ae2/nJ9Bpad+b106owRup+/1Mypouhd3+6TZ1FELpV3SlDAN+ftZuei9oM4P+NwJUPZJiltSp26oJUnmiIZjaJKOCD7xqVcrL6VS297IwGKQ5JeRxYvP6kFXigjjMvwn30wx0NdVePl4fIq9q6Ioh9Q0I X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1378; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1378; X-Forefront-PRVS: 07658B8EA3 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEzNzg7MjM6RzFkVXhsTU5xTGFKVUcwaEJwMFVIeDFV?= =?utf-8?B?bE9kMzBFaWphRVBSMFkwcGl6QUIxeExhTEV3OWFaQkh1RTBoeU92SDJBQTU2?= =?utf-8?B?QUg3M09WQmRwL1JkbmU5bEZLSnlMTnEzd0FrN1RjcDNUeGo4SkhGS3dQTmxr?= =?utf-8?B?YkUyR2IvMnVQUzgrRnlqWWhDblhCWldYdi84NEwrU3dESjNCNGlnQXViSDZZ?= =?utf-8?B?dkEvMUFtMzJld0toYWM5SEErNGJtUmJTUnFiNGw1V3kvVzArQjdmK2tIVkZV?= =?utf-8?B?YlI5Zlc3YlFMV0ZzeG1UUE1UMnBNVXhISFEwdmFpdjRUSEl4eGdVak90MXE3?= =?utf-8?B?RWNWWlhZU29WOE55cEJXdVdRRS9KbmRhZHRaL0dla25SV0hoUHdLWUJkQzZE?= =?utf-8?B?NFR2UDM3WkZkZ2I4RXBRMlVRYlpMNWwvUEd2aHRXUDJuRlBMYTN3QnoxWHVM?= =?utf-8?B?Ry9MUU5GcnlSQ2Ywc1NQR2FyejgrdWk3Um5HT2JRVDBoUGhzUGpaSDZLOGtH?= =?utf-8?B?Z1NnTjcxODBub0lodVc3enVOczZ0Vk0ra2lqZ21VOUdBTVlyQ3JDc0xJSzZz?= =?utf-8?B?K25XYnVxWEtCVmR5MzRlc3JNa0xHV2l6UW9JMXNGYjlkUHpwaGZJN3plUVBO?= =?utf-8?B?MTBPSVVzaXRrS2hvaWpxZUhLQStBU0UwZnZobDdDS1p6a05sWnArYzBaOUFV?= =?utf-8?B?NGFpMGpXdTBLQmYzUnJkaHRnejU4S21FNHU3S1lZUFVrRFlPZVYzdUkwOW9v?= =?utf-8?B?OXRXc0JNQVkzclNtNXB3RFdRNGJxc29Kbmw5NXVBdXgyWm9PYjJTUlpmd3Uv?= =?utf-8?B?OS83WEFBWlZIMDJxYWJTYzcvSTYwTWZTQWlEd0h6eHFnMDRDZXlpU0RRODZi?= =?utf-8?B?NkFHVHQ0S2RJODE3cGVBZVZyWC8zSFRWcmZ0Q0Y0Y21XUjM5TEl5Y2tuZlQ5?= =?utf-8?B?ZFNYVnJUeHlIY2pDVTVPSDB3czVWbXR5bDZRbkM2d2g4cGduRXdEWmtsQTVx?= =?utf-8?B?Um9vNExpUkFCZUN2dUEyWVZaR1dDOWZRbFh0ZHliZmUyMDJaUFZXalU2Sjdu?= =?utf-8?B?ZUJpVTVlTmJ4bVhhbzFoRHBVaUdmd3BSNW1KalplYW8xMDNaR2RLblVsZm9u?= =?utf-8?B?MEVsR1VHVXlFOVRGeXgyNng0NTF6MWpDS0FDTWc3SHdqV01wOTFNK1Q0SXZR?= =?utf-8?B?alFVOUV2enRsOEFvZ041bTdJNUYxWlRHYkh2Zm1wcUZYNE0wQi9ITDF4bmhx?= =?utf-8?B?cWpOMVhwRUNyYWs1Qlp4Q2RFZTZnK2ZsMmRCZGhBVzByZm42M2V0bmNsaG51?= =?utf-8?B?ZXpZQ0Y3UUpnbTQrQT09?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1378; 5:YNqN1nqQfC5QNlX6tNbqUBj38CSogT60G0r6PpPPto6QLLVdjjtDzzgpmxG1G3Augsk+TgoScTPin+28cmIerWHsruKSHbSd4HnwVkKPZiXVZbIgMb9z2tqEYsRWxrYiHS7Ca4FYrQSPaGudO0ZMVw==; 24:lfQ+AvqjljWOxtph0ezWjQSQ8lNi7kzdWayWD0PEmY2mRqqjatprHjrM5TEi+SlcwhnipfCtTXuhZ/P9QrpZxYbf4ePWH0XPYGNgit5fcfs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2015 16:59:43.6334 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.17]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1378 Archived-At: Cc: ietf-ssh@NetBSD.org, "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 16:59:49 -0000 Niels M=C3=B6ller writes: > "Mark D. Baushke" writes: >=20 > > Given that current implementatons of this informational RFC are using > > AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track > > Cipher algorithms use lowercase with '-' as word separators, I would > > suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and > > that they should NOT be added to the MAC Algorithms Names in IANA. >=20 > THe openssh way of ignoring the mac negotiation completely, if an aead > cipher is negotiated, seems nice and simple. How does it interact with > first_kex_packet_follows logic, does that need any clarification (a > simple rule is to say that if both sides advertise the same aead cipher > as the first cipher, then for first_kex_packet_follows purposes, the mac > negotiation is considered successful and correctly guessed)? I am not sure that first_kex_packet_follows would guess properly because the first listed algorithm must be the same on both sides and I am not sure that will be true very often given the number of different host key algorithms that exist. > Not sure if it has a place in the same rfc, but I think a proper > specification for use aead is quite inportant. Okay. Thanks, -- Mark From nobody Thu Nov 19 11:42:42 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277771B349C for ; Thu, 19 Nov 2015 11:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLTd6gmzCJ1u for ; Thu, 19 Nov 2015 11:42:39 -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 590A01B3499 for ; Thu, 19 Nov 2015 11:42:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 84AAABE8A for ; Thu, 19 Nov 2015 19:42:35 +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 ivvCX5ccMMl1 for ; Thu, 19 Nov 2015 19:42:34 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A959ABE7D for ; Thu, 19 Nov 2015 19:42:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447962154; bh=D/gaEX1kgSHK4Y1sPDdFXKYG/Xo0X5Flm9fGChMsMkM=; h=To:From:Subject:Date:From; b=bhYFsAFp5qZtpuP0nrp1pUH90OG2sZnTFuxxpW2XIGQFpl5F1GEkanFuvRyO9GJ5A lwTi/Hgxmf4F7KqJi8YhFDMjXT15fEU4FlENbbwegr81NkMU36gnC1dgEpAcMCdgkj er/ww2vYxYgAwXu8BBGbpY6Nkz1nGpgyntXzL9Es= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564E2628.80500@cs.tcd.ie> Date: Thu, 19 Nov 2015 19:42:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] ietf94 saag meeting draft minutes... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:42:41 -0000 ...are at [1], please send needed corrections by end of next week. Thanks, S. From nobody Thu Nov 19 11:43:47 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1551B34AD for ; Thu, 19 Nov 2015 11:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrpHWB6dqhSr for ; Thu, 19 Nov 2015 11:43:44 -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 151671B34A3 for ; Thu, 19 Nov 2015 11:43:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D6408BE7D for ; Thu, 19 Nov 2015 19:43:40 +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 9VBtzIQ971Rr for ; Thu, 19 Nov 2015 19:43:39 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5B40EBE8A for ; Thu, 19 Nov 2015 19:43:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1447962219; bh=q7GV0bC8SKxl2P6lq6yvx12VgW8GdauKOc1ePxBLEyw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iFxjmqlzBJ3eWAjPlXKLwxEBFP7H+AoYs9KLqD3GipDpaVDEy9EwG60u4UAKiK3GW +tvDEtOcUYsT7kdt+F0Qrw95DoATPtiMYFyrx5tp7GdOSEFpSwVOB/Fuhy5taiYrD0 ILS6bAHlE6xgLV4uCBdCnW2bMa+ryh3f++G/eEQI= To: "saag@ietf.org" References: <564E2628.80500@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564E2667.5000303@cs.tcd.ie> Date: Thu, 19 Nov 2015 19:43:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564E2628.80500@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] ietf94 saag meeting draft minutes... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 19:43:46 -0000 On 19/11/15 19:42, Stephen Farrell wrote: > > ...are at [1], please send needed corrections by end of > next week. > > Thanks, > S. Sorry, [1] https://www.ietf.org/proceedings/94/minutes/minutes-94-saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Fri Nov 20 02:51:16 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF281B2D59 for ; Fri, 20 Nov 2015 02:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.485 X-Spam-Level: X-Spam-Status: No, score=-4.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuOdqyO0atMd for ; Fri, 20 Nov 2015 02:51:11 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1C91B2D53 for ; Fri, 20 Nov 2015 02:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1448016671; x=1479552671; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=H7vdiTMYgkiKsqvZYQagtHi7q/gkjBex/8PTOBTQue0=; b=wdqmt67CY5zjGicFGwS9YH4x/TZ1zkxRSMXur39jOtlQxAx+cq5vIbrk AZDbGCvIpPpL1eouQYOBJk869yKkcV3NQ6BmRlOArAUbple4SVfKGKhge UwL2CfXWgcX999GVm7Ss+o5ayhkEpCBL6HjsSLFoJTfpudM1EQ9ICXHtk uuYBVXiyTkg+sl7p9SnOvxNdE7r/NoxB4RulNiRQlsQFmT2PmW/tLzkqj GQOwDR7p4P9JAFKcot429+SGlS5EWwGNm+SQg+oj3/F79F9FZHud5a30Z kQ9pB8vj4chrOctx0Np3s3lr0xwKfnspKZN1/qATISxOao+DMerUlUZLi A==; X-IronPort-AV: E=Sophos;i="5.20,321,1444647600"; d="scan'208";a="55197602" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe4.UoA.auckland.ac.nz) ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Nov 2015 23:51:09 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Fri, 20 Nov 2015 23:51:09 +1300 From: Peter Gutmann To: "Mark D. Baushke" , =?iso-8859-1?Q?Niels_M=F6ller?= Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIpFOlpipP2MZvkGbJ40Yn5ajpZ6jklENgAEqGXU= Date: Fri, 20 Nov 2015 10:51:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B6AA52@uxcn10-5.UoA.auckland.ac.nz> References: <564C5FCC.8080107@cs.tcd.ie> <89505.1447867474@eng-mail01.juniper.net> , <89694.1447952378@eng-mail01.juniper.net> In-Reply-To: <89694.1447952378@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 10:51:15 -0000 Mark D. Baushke writes:=0A= =0A= >I am not sure that first_kex_packet_follows would guess properly because t= he=0A= >first listed algorithm must be the same on both sides and I am not sure th= at=0A= >will be true very often given the number of different host key algorithms= =0A= >that exist.=0A= =0A= How widely is first_kex_packet_follows used in practice? That's another th= ing=0A= I'd like to see deprecated in any future changes (see the SimpleSSH proposa= l I=0A= mentioned a week or so back), it vastly complicates the handshake when you= =0A= have to guess at things and potentially roll back to the previous state and= =0A= try again. Best-case if you've got identical, identially-configured=0A= implementations at both ends you save a whole RTT, but more common case you= =0A= have a lot of extra complexity and overhead as you roll back from the=0A= incorrectly-guessed keyex and try again.=0A= =0A= Peter.=0A= From nobody Fri Nov 20 10:01:25 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0E1B3AE7 for ; Fri, 20 Nov 2015 10:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGlVPW0zbW9R for ; Fri, 20 Nov 2015 10:01:23 -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 0E1221B3AEA for ; Fri, 20 Nov 2015 10:01:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6706ABE7B for ; Fri, 20 Nov 2015 18:01:21 +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 BGYro2icw7MM for ; Fri, 20 Nov 2015 18:01:20 +0000 (GMT) Received: from [10.87.48.95] (unknown [86.46.27.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B11B5BE77 for ; Fri, 20 Nov 2015 18:01:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448042480; bh=mli5YaxwLmYoW5ivCHhuu8q5aZ+f9sO4aX3vtjPkNjs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rJeWMcU3sP521/QFNVroiHs0bgpqD8BC/HBKGJ36DgX/nRkcWTVgm7dpTLTovuIY8 4IIqeA7DoYDX1bOGC0R3Pc3CRveLIU/boa7rnzwWREQzrPAiuGu+csa1r2SbpU/jZT Fy8w35MSs1sGP2VX4gztZFClFSzS3DfKrJa1uBGs= To: "saag@ietf.org" References: <564CB568.2060901@cs.tcd.ie> <564CBB6C.2080406@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <564F5FEF.2030803@cs.tcd.ie> Date: Fri, 20 Nov 2015 18:01:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564CBB6C.2080406@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 18:01:24 -0000 Hiya, On 18/11/15 17:54, Stephen Farrell wrote: > That'd work for me. I'll wait and add it tomorrow(ish) in case folks > have better wording or objections. So I've made that change and am happy enough that we should have enough interested folks. I'll go ahead and move the chartering along and ask that a mailing list be created. I'll send a mail here when that's done. If the charter and work-items etc. need more debate we can do that on the new list. Thanks, S. From nobody Fri Nov 20 13:21:58 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8741B3E34 for ; Fri, 20 Nov 2015 13:21:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rjglkqt6Smh for ; Fri, 20 Nov 2015 13:21:55 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B16F41B3E33 for ; Fri, 20 Nov 2015 13:21:54 -0800 (PST) X-AuditID: c1b4fb2d-f79626d000004282-45-564f8ef0845c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.D1.17026.0FE8F465; Fri, 20 Nov 2015 22:21:52 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.72]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Fri, 20 Nov 2015 22:21:52 +0100 From: John Mattsson To: Stephen Farrell , Simon Josefsson , Paul Hoffman Thread-Topic: [saag] potential new wg - curdle... Thread-Index: AQHRIiMUyxwHZkFPGkGCMx9vxuLjV56iCtIAgAAmk0WAAAUZgIAAKBGAgAMQGwA= Date: Fri, 20 Nov 2015 21:21:51 +0000 Message-ID: References: <564C5FCC.8080107@cs.tcd.ie> <564CAF70.3030605@cs.tcd.ie> <5E04953F-6215-44E0-99B0-89E384DD099A@vpnc.org> <87twoj13uy.fsf@latte.josefsson.org> <564D0B3D.90405@cs.tcd.ie> In-Reply-To: <564D0B3D.90405@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [153.88.183.150] Content-Type: multipart/mixed; boundary="_002_D27546CF413ECjohnmattssonericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2K7nO6HPv8wgwfXtSxurf/CajGlv5PJ 4t6WS+wW0/deY3dg8VjbfZXNY8mSn0weM89cZPf4PPsqcwBLFJdNSmpOZllqkb5dAlfGnt4b 7AXNARVNey8wNTBe9O1i5OSQEDCRONvbxgJhi0lcuLeeDcQWEjjMKHG4NaWLkQvIXswo8frW GmaQBJuAgcTcPQ1gRSICdRK7f88Bs5kFlCXe/nnCBGILA9VsXLqNCaLGUOLgrv1AvRxAtp/E 21MCIGEWAVWJ979/grXyCphLtG8+zwKxayaTxMdvX8B2cQqoS+z8uoMVxGYEOu77qTVMELvE JW49mc8EcbSIxMOLp9kgbFGJl4//sYLsEhXQk9izXBIirCSxYvslRojWMImjyz5B7RWUODnz CcsERrFZSKbOQlI2C0nZLKCpzAKaEut36UOUWEs8efWXHcJWlJjS/RDKNpH4/n8ZlK0ssf7S SsZZQJ8xC6xmlOhYPJcJpvlVy1YWZM0LGLlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgQm g4NbfuvuYFz92vEQowAHoxIPr4GMX5gQa2JZcWXuIUYVoDmPNqy+wCjFkpefl6okwnvgHVCa NyWxsiq1KD++qDQntfgQozQHi5I4bwvTg1AhgfTEktTs1NSC1CKYLBMHp1QDY9ziU7LSFilv N8e8/F6x9ZbCxyTHgDNaCzkNe6QMUl7V3mF6r50m1Pcho0tUPkmel493puv139FfJwkVJl5U X6TM0ZV0pT95m4/aLbnUttXs3cFrhNVmZTMoLGrdeSnlgvL9RPdr4Qk7i2ZdezfhgfdPn1CW gIWzl1teaSle1niyK9JDQ+GLEktxRqKhFnNRcSIAeF3S+w4DAAA= Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] potential new wg - curdle... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 21:21:57 -0000 --_002_D27546CF413ECjohnmattssonericssoncom_ Content-Type: text/plain; charset="utf-8" Content-ID: <9870C171F173414CB446FD9546207992@ericsson.com> Content-Transfer-Encoding: base64 DQoNCk9uIDE5LzExLzE1IDAwOjM1LCAiU3RlcGhlbiBGYXJyZWxsIiA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT4gd3JvdGU6DQoNCj4NCj4NCj5PbiAxOC8xMS8xNSAyMDoxMiwgSm9obiBNYXR0 c3NvbiB3cm90ZToNCj4+IFNpbW9uIHNhaWQ6DQo+Pj4gPkkgc3VwcG9zZSB0aGUgaW50ZW50aW9u IGlzIHRvIGRlcHJlY2F0ZSAib2J2aW91c2x5IGJhZCIgYWxnb3JpdGhtcw0KPj4+bGlrZQ0KPj4+ ID5yYzIsIHJjNCwgbWQyLCBtZDQsIG1kNSwgY29sbGlzaW9uLXJlc2lzdGFudCB1c2VzIG9mIHNo YTEsIHNpbmdsZS1kZXMsDQo+Pj4gPnNtYWxsIGJsb2NrICg8MTI4Yikgc2l6ZSBibG9jayBjaXBo ZXJzLCA8PTEwMjQgYml0IERTQS9SU0EvREgsIDwyMjRiaXQNCj4+PiA+RUNDLCBldGMsIHNob3Vs ZCB3ZSByZWFsaXplIGFueSBvZiB0aGVzZSBleGFtcGxlcyB3aGVuIGdvaW5nIHRocm91Z2gNCj4+ PiA+cHJvdG9jb2xzLiAgQm9yZGVybGluZSBjYXNlcyBtYXkgaW5jbHVkZSBITUFDLU1ENSBhbmQg MjI0LWJpdCBFQ0MuDQo+PiArMSAoQnV0IGFkZCB0d28ta2V5IHRyaXBwbGUtZGVzIGFuZCBjaGFu Z2UgdG8gPDIwNDggYml0IERTQS9SU0EvREgpLg0KPg0KPkkgdGhpbmsgdGhlIGFib3ZlIGNoYXJh Y3RlcmlzZXMgdGhlIGRlcHJlY2F0aW9uIHN0dWZmIHdlbGwuIFRoaXMgcGFydA0KPm9mIHRoZSB3 b3JrIGlzIG1lYW50IHRvIHRpZHkgdXAgYW5kIG5vdCBiZSByZXZvbHV0aW9uYXJ5Oi0pDQo+DQo+ Uy4NCg0KQW5vdGhlciBhbGdvcml0aG0gdGhhdCBzaG91bGQgYmUgZGVwcmVjYXRlZCBpcyAiQUVT LUdDTSB3aXRoIGEgOCBvY3RldA0KSUNW4oCdIGlmIGl0IGlzIHNwZWNpZmllZCBhbnl3aGVyZSBl bHNlIHRoYW4gZm9yIEVTUCBhbmQgSUtFdjIsIHdoaWNoIGlzIG5vdA0KaW4gc2NvcGUgZm9yIGN1 cmRsZS4gUkZDNDEwNiB3YXMgcHVibGlzaGVkIHNob3J0bHkgYWZ0ZXIgRmVyZ3Vzc29uDQpwdWJs aXNoZWQgaGlzIHBhcGVyIG9uIGF1dGhlbnRpY2F0aW9uIHdlYWtuZXNzZXMgb24gdGhlIHVzZSBv ZiBHQ00gd2l0aA0Kc2hvcnQgdGFncy4gDQpodHRwOi8vY3NyYy5uaXN0Lmdvdi9ncm91cHMvU1Qv dG9vbGtpdC9CQ00vZG9jdW1lbnRzL2NvbW1lbnRzL0NXQy1HQ00vRmVyZ3UNCnNvbjIucGRmDQoN ClJGQzQxMDYgZG9lcyB0aGVyZWZvcmUgbm90IGZ1bGZpbCB0aGUgbWl0aWdhdGlvbiByZXF1aXJl bWVudHMgdGhhdCBOSVNUDQpzcGVjaWZpZWQgZm9yIHRoZSB1c2Ugb2Ygc2hvcnQgdGFncyAoQW5u ZXggQyBvZiBTUCA4MDAtMzhEKS4NCg0KRnVydGhlcm1vcmUsIG1vc3QgZGVwbG95bWVudHMgb2Yg SVBzZWMgZG9lcyBub3QgZnVsZmlsIHRoZSBOSVNUIGd1aWRlbGluZXMNCm9mIG5vdCBwcm92aWRp bmcgaW5mb3JtYXRpb24gb2Ygc3VjY2Vzc2Z1bCBmb3JnZXJpZXMuIFRoaXMgaXMgc2hvd24gaW4g dGhlDQpmb2xsb3dpbmcgYW5hbHlzaXMgdGhhdCBJIHdpbGwgc29vbiB1cGxvYWQgdG8gdGhlIENy eXB0b2xvZ3kgZVByaW50DQpBcmNoaXZlIChVcGRhdGUgb2YgaHR0cHM6Ly9lcHJpbnQuaWFjci5v cmcvMjAxNS80NzcpOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KW1JGQzQxMDZdIHNwZWNpZmll cyB0aGUgdXNlIG9mIEdDTSB3aXRoIDY0LCA5NiwgYW5kIDEyOCBiaXQgdGFncy4gVGhlDQpzcGVj aWZpY2F0aW9uIGRvZXMgbm90IGRpc2N1c3MgdGhlIHByb2JsZW1zIHdpdGggc2hvcnQgdGFncyBh bmQgZG9lcyBub3QNCnJlcXVpcmUgaW1wbGVtZW50YXRpb25zIHRvIHJlc3RyaWN0IHRoZSBtYXhp bXVtIG1lc3NhZ2UgbGVuZ3RoIEwgb3IgdGhlDQptYXhpbXVtIG51bWJlciBvZiBpbnZvY2F0aW9u cyBxIG9mIHRoZSBhdXRoZW50aWNhdGVkIGRlY3J5cHRpb24gZnVuY3Rpb24uDQpXaGlsZSBFU1Ag bGltaXRzIHRoZSBBQUQgdG8gbmVjZXNzYXJ5IGhlYWRlciBpbmZvcm1hdGlvbiBhbmQgc2lsZW50 bHkNCmRpc2NhcmRzIGRhdGFncmFtcyB0aGF0IGZhaWwgdGhlIGludGVncml0eSBjaGVjaywgRVNQ IGRvZXMgbm90IHNpbGVudGx5DQpkaXNjYXJkIGRhdGFncmFtcyB0aGF0IHBhc3NlcyB0aGUgaW50 ZWdyaXR5IGNoZWNrIGFuZCBpbmZvcm1hdGlvbiBsZWFrYWdlDQpyZWdhcmRpbmcgdGhlIGludGVn cml0eSBvZiBpbmRpdmlkdWFsIHBhY2tldHMgaXMgdGhlcmVmb3JlIHBvc3NpYmxlIGluDQptYW55 IGRlcGxveW1lbnRzLg0KDQotIElmIGFueSByZXF1ZXN0LXJlc3BvbnNlIHByb3RvY29sIGlzIHNl bnQgb3ZlciBhbiBJUHNlYyBwcm90ZWN0ZWQgcGF0aCwNCmFuIGF0dGFja2VyIGNhbiBhdHRlbXB0 IGZvcmdlcnkgYnkgbW9kaWZ5aW5nIGEgZGF0YWdyYW0gY29udGFpbmluZyBhDQpyZXF1ZXN0IChl LmcuIEhUVFAgR0VUKS4gSWYgaW50ZWdyaXR5IGZhaWxzLCB0aGUgSVBzZWMgaW1wbGVtZW50YXRp b24gd2lsbA0Kc2lsZW50bHkgZGlzY2FyZCB0aGUgZGF0YWdyYW0uIElmIHRoZSBkYXRhZ3JhbSBw YXNzZXMgdGhlIGludGVncml0eSBjaGVjaywNCmEgcmVzcG9uc2UgKGUuZy4gMjAwIE9LKSB3aWxs IGJlIHNlbnQuIFRoZSBkYXRhZ3JhbSBjb250YWluaW5nIHRoZQ0KcmVzcG9uc2Ugd2lsbCBhbHNv IGJlIGVuY3J5cHRlZCwgYnV0IGFzc3VtaW5nIHNtYWxsIGFtb3VudHMgb2Ygb3RoZXINCnRyYWZm aWMgKHRoZSBhdHRhY2tlciBtYXkgZS5nLiBibG9jayBjZXJ0YWluIHRyYWZmaWMpIHRoZSBhdHRh Y2tlciBjYW4gc2VlDQp0aGF0IGEgcmVzcG9uc2Ugd2FzIHNlbnQgYW5kIGNvbmNsdWRlIHRoYXQg dGhlIGZvcmdlcnkgd2FzIHN1Y2Nlc3NmdWwuDQoNCi0gSWYgdHVubmVsIG1vZGUgaXMgdXNlZCwg dGhlIGF0dGFja2VyIG1heSBtb2RpZnkgdGhlIGlubmVyIGRlc3RpbmF0aW9uIElQDQphZGRyZXNz IHNvIHRoYXQgdGhlIHBhY2tldCBpbiBjYXNlIG9mIGEgc3VjY2Vzc2Z1bCBmb3JnZXJ5IGlzIHJv dXRlZCB0bw0KdGhlIGFkdmVyc2FyeSBpdHNlbGYuDQoNCklmIG11bHRpY2FzdCBpcyB1c2VkIFtS RkM1Mzc0XSwgdGhlIGF0dGFja2VyIG1heSBhdHRlbXB0IGZvcmdlcnkgdG93YXJkcw0Kc2V2ZXJh bCBpbnN0YW5jZXMgb2YgdGhlIEdDTSBkZWNyeXB0aW9uIGZ1bmN0aW9uIGluIHBhcmFsbGVsLCBh bmQgdGhlDQptYXhpbXVtIG51bWJlciBvZiBpbnZvY2F0aW9ucyBxIG9mIHRoZSBkZWNyeXB0aW9u IGZ1bmN0aW9uIHdvdWxkIG5lZWQgdG8NCmJlIGNhbGN1bGF0ZWQgb3ZlciBhbGwgaW5zdGFuY2Vz IG9mIHRoZSBkZWNyeXB0aW9uIGZ1bmN0aW9uLiBUaGVvcmV0aWNhbGx5DQp0aGlzIGNvdWxkIGJl IGRvbmUgd2l0aCBzeW5jaHJvbml6YXRpb24sIGJ1dCBpbiBwcmFjdGljZSB0aGUgb25seSBzb2x1 dGlvbg0Kd291bGQgYmUgdG8gcmVzdHJpY3QgdGhlIG51bWJlciBvZiBpbnZvY2F0aW9ucyBvZiBl YWNoIGluc3RhbmNlIHRvIHEvcg0Kd2hlcmUgciBpcyB0aGUgdG90YWwgbnVtYmVyIG9mIHJlY2Vp dmVycy4gVGhpcyBtYWtlcyBxL3IgaW1wcmFjdGljYWxseQ0Kc21hbGwgYW5kIG1ha2VzIHRoZSBz eXN0ZW0gdnVsbmVyYWJsZSB0byBkZW5pYWwtb2Ytc2VydmljZSBhdHRhY2tzLg0KDQpJUHNlYyBF U1Agd2l0aCBHQ00gYW5kIDY0LWJpdCB0YWdzIG9mZmVycyA2NCBiaXRzIG9mIHNlY3VyaXR5IGFn YWluc3QNCm9ubGluZSBhdXRoZW50aWNhdGlvbiBrZXkgcmVjb3ZlcnkgYXR0YWNrcyBhbmQgSVBz ZWMgRVNQIHdpdGggR0NNIGFuZA0KOTYtYml0IHRhZ3Mgb2ZmZXJzIDk2IGJpdHMgb2Ygc2VjdXJp dHkuIFRoZSBhdHRhY2tzIHNlZW0gcG9zc2libGUgaW4NCnByYWN0aWNlLg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLQ0KDQoNCg0KDQoNCg0KDQo= --_002_D27546CF413ECjohnmattssonericssoncom_ Content-Type: application/xml; name="default[4].xml" Content-Description: default[4].xml Content-Disposition: attachment; filename="default[4].xml"; size=3222; creation-date="Fri, 20 Nov 2015 21:21:51 GMT"; modification-date="Fri, 20 Nov 2015 21:21:51 GMT" Content-ID: <47C21B7A29EF4148B8B04C9274119229@ericsson.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_002_D27546CF413ECjohnmattssonericssoncom_-- From nobody Sun Nov 22 07:05:52 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416FC1A8A79 for ; Sun, 22 Nov 2015 07:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 GVLXWnT5dHay for ; Sun, 22 Nov 2015 07:05:50 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 DBA2C1A8A78 for ; Sun, 22 Nov 2015 07:05:49 -0800 (PST) Received: by lfdl133 with SMTP id l133so12946405lfd.2 for ; Sun, 22 Nov 2015 07:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=P9g6tpPvah/XDyHCR7vZ1RO+4uafSWAAPQJDdRabDDE=; b=Ry2awS91eSvEU7udhIi6RIv3W59uevc1f4lDv1DrMVjD+RpkvUyx0ikPd2e0/9L9+i TZdw1x8kTFycc8j+nviLEIiotvWnw7tuNmMUujTOKtg6N4EHxI/LKPcOOPQg72XlVdZA vOCzDAE17xTZP6TKjI4sjidggJZe44MZuDuajUoLbp6q4d9IkZfWZskup+QsWeOjMP4G JAUb9hil86EHQKvHyNzY+rq2DNHUsJRi5DzmGxZSyuYxrO8UeZOCUpCclfBXSkPt0vka ez3xLQpE6qwLyq3RJ76Rd3X/pkwklMOQl/EFHwHOqfTmRfjRXXarHwOaisVS191JfVI+ bGiw== MIME-Version: 1.0 X-Received: by 10.25.206.203 with SMTP id e194mr7441004lfg.166.1448204747964; Sun, 22 Nov 2015 07:05:47 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Sun, 22 Nov 2015 07:05:47 -0800 (PST) Date: Sun, 22 Nov 2015 10:05:47 -0500 X-Google-Sender-Auth: pyJp8WqbO2nBMc4F1kOu_kMSJQg Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] Is Apple ever going to fix its certificate chain handling code? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 15:05:51 -0000 I am still getting validation failures for perfectly TLS good certs on Safari and Chrome. The bug is caused by the path math failing when a machine has somehow acquired a cert chain containing a roll over root that isn't in the Apple trust store. Reporting it here since reports to Apple security team over the past two years have had absolutely no effect or resulted in a response. Suggest you guys fix it before I appear on CNBC or the like. I don't think Tim Cook would appreciate discovering you folk are asleep at the switch on security and you never ever respond to bug reports. From nobody Sun Nov 22 15:39:44 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE281B29B5 for ; Sun, 22 Nov 2015 15:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 73W2IQzq6GJS for ; Sun, 22 Nov 2015 15:39:41 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7137D1B29B8 for ; Sun, 22 Nov 2015 15:39:41 -0800 (PST) Received: by lbbcs9 with SMTP id cs9so87117254lbb.1 for ; Sun, 22 Nov 2015 15:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=PWuwRsqgZqNdWlskvRl/OOw/7yACrn55LpLfD2Nv+h4=; b=xzwVlBfD7RKynLptAozyw/2ZnhpYag8k9z5qpjqNcJz9aPEZqE+GnUYM36Ke1xMCI9 86m7YTAJ4iqk1AudF442+To9QUBzZ33mqbRRKRBPhacXCG2V2YFTkSxqaUuEhTYqk+Rk 9tt080jU62MwcWAFbzgEyFbLfTn6bbgMkwnlFe/gJI04+Bf+BmaDaKSVWGoEG90HnBos eE2XyAYvpxI/FuO9eC4kMLzRehAGFjxEF3/lkDuOPlo/0Y8BueHcObBaxbm8amwmiumZ WAb2b1dd8gaOnkBBiFLzviEDTJvAQyrobGxDfGxyBSMt/Ik0VopPxp/V0gOsrvScAM25 gYxA== MIME-Version: 1.0 X-Received: by 10.112.16.135 with SMTP id g7mr10254071lbd.80.1448235579441; Sun, 22 Nov 2015 15:39:39 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Sun, 22 Nov 2015 15:39:39 -0800 (PST) In-Reply-To: References: Date: Sun, 22 Nov 2015 18:39:39 -0500 X-Google-Sender-Auth: LaJgNYhBXqH9ibkwYgd0x57vYiU Message-ID: From: Phillip Hallam-Baker To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [saag] Is Apple ever going to fix its certificate chain handling code? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 23:39:43 -0000 Just to be clear, I realize this is not a SAAG responsibility. It is just that at this point I am running out of options and I would prefer to avoid more aggressive tactics. I am quite capable of thinking up a cute name for the attack and calling up the trade press. But I prefer to avoid such approaches. I note that under Apple Inc. bylaws, 5.14 any business to be put before the shareholder's meeting has to be notified to the company Secretary in the next few weeks. On Sun, Nov 22, 2015 at 10:05 AM, Phillip Hallam-Baker wrote: > I am still getting validation failures for perfectly TLS good certs on > Safari and Chrome. > > The bug is caused by the path math failing when a machine has somehow > acquired a cert chain containing a roll over root that isn't in the > Apple trust store. > > Reporting it here since reports to Apple security team over the past > two years have had absolutely no effect or resulted in a response. > Suggest you guys fix it before I appear on CNBC or the like. I don't > think Tim Cook would appreciate discovering you folk are asleep at the > switch on security and you never ever respond to bug reports. From nobody Wed Nov 25 02:09:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA11A1A2D for ; Wed, 25 Nov 2015 02:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 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, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3Sa9Rvb3J8I for ; Wed, 25 Nov 2015 02:09:27 -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 0C8531A1A10 for ; Wed, 25 Nov 2015 02:09:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E10A3BE25 for ; Wed, 25 Nov 2015 10:09:24 +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 x2T-u5QJFWsp for ; Wed, 25 Nov 2015 10:09:18 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.27.82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D424BDF9 for ; Wed, 25 Nov 2015 10:09:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1448446158; bh=Az1m1F3vP7iJf+rOcmz5KWHclq0ltJGoP4zMvxEbFHk=; h=Subject:References:To:From:Date:In-Reply-To:From; b=wFytenOwPhwTtRdBNuOZsr2V7KjANPYTVob97KfoxFd7Jxb4TfHAKVWWmrYj9w8p6 6MZrfEw513G3HS4HXhlKR/SM6NpD1XMtBRTqdhK6TIdnuKEWYrQjTtOhdWbEc7gjSD QgphcwGM/0sltmlyczAHAyeLRtPmVn8Z6b738YHI= References: To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: <565588BC.3080202@cs.tcd.ie> Date: Wed, 25 Nov 2015 10:09:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: Welcome to the "Curdle" mailing list X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 10:09:29 -0000 Hiya, The mailing list for that curdle thing is now setup. Please subscribe if interested and we can continue to discuss there (in a few days, once folks have had a chance to get on the list) Cheers, S. -------- Forwarded Message -------- Subject: Welcome to the "Curdle" mailing list Date: Wed, 25 Nov 2015 01:30:19 -0800 From: curdle-request@ietf.org To: stephen.farrell@cs.tcd.ie Welcome to the Curdle@ietf.org mailing list! To post to this list, send your message to: curdle@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Nov 30 09:09:59 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4683E1AD0BB for ; Mon, 30 Nov 2015 09:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.499 X-Spam-Level: X-Spam-Status: No, score=-100.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6tjGrQ3j_tl for ; Mon, 30 Nov 2015 09:09:49 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 198AA1AD09F for ; Mon, 30 Nov 2015 09:09:49 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 96E57F2404B for ; Mon, 30 Nov 2015 12:09:38 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 5XGvAmZhNV+y for ; Mon, 30 Nov 2015 12:08:20 -0500 (EST) Received: from [192.168.2.104] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 0EFC0F2403B for ; Mon, 30 Nov 2015 12:09:29 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary=Apple-Mail-45-297239700 Date: Mon, 30 Nov 2015 12:09:18 -0500 References: To: IETF SAAG Message-Id: <6AC91056-EB1C-42A3-915F-0F446C0F8867@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [saag] Fwd: Reminder: NIST Requests Comments on FIPS 186-4, Digital Signature Standard X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 17:09:53 -0000 --Apple-Mail-45-297239700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "Caswell, Sara J." > Date: November 30, 2015 11:47:25 AM EST > Subject: NIST Requests Comments on FIPS 186-4, Digital Signature = Standard >=20 > Reminder: Deadline for comments is this Friday, December 4th. > =20 > NIST requests comments on Federal Information Processing Standard = (FIPS) 186-4, Digital Signature Standard, which has been in effect since = July 2013. FIPS 186-4 specifies three techniques for the generation and = verification of digital signatures that can be used for the protection = of data: RSA, DSA, and ECDSA, along with a set of elliptic curves = recommended for government use. NIST is primarily seeking comments on = the recommended elliptic curves specified in Appendix D of the FIPS, but = comments on other areas of the FIPS will also be considered. FIPS 186-4 = is available at http://dx.doi.org/10.6028/NIST.FIPS.186-4. > =20 > The Federal Register Notice (https://federalregister.gov/a/2015-26539) = provides additional background information, including questions that = NIST is especially interested in having addressed. > =20 > Comments on FIPS 186-4 may be sent electronically to = FIPS186-comments@nist.gov with "Comment on FIPS 186" in the subject = line. The deadline for comments is December 4, 2015. > =20 >=20 --Apple-Mail-45-297239700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: "Caswell, Sara J." = <sara.caswell@nist.gov>
Date: November 30, 2015 11:47:25 AM = EST
Subject: NIST Requests Comments on FIPS 186-4, Digital = Signature Standard

Reminder: Deadline for comments is this Friday, = December 4th.
NIST requests comments on Federal = Information Processing Standard (FIPS) 186-4, Digital Signature = Standard, which has been in effect since July 2013. FIPS 186-4 specifies = three techniques for the generation and verification of digital = signatures that can be used for the protection of data: RSA, DSA, and = ECDSA, along with a set of elliptic curves recommended for government = use. NIST is primarily seeking comments on the recommended elliptic = curves specified in Appendix D of the FIPS, but comments on other areas = of the FIPS will also be considered. FIPS 186-4 is available at