From nobody Mon Sep 1 01:28:43 2014 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 98AB31A01EB; Mon, 1 Sep 2014 01:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qG-_GF12Alrw; Mon, 1 Sep 2014 01:28:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F15711A01E8; Mon, 1 Sep 2014 01:28:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140901082838.26648.23612.idtracker@ietfa.amsl.com> Date: Mon, 01 Sep 2014 01:28:38 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IZHC6bCMv7RD8BTXcNyNwf-JAqc Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Barry Leiba's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 08:28:40 -0000 Barry Leiba has entered the following ballot position for draft-dukhovni-opportunistic-security-04: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm going to press "defer" on this, because I have concerns about the consensus here, and because of the IGF meeting I won't have time to chase it down and satisfy myself. Primary among my concerns is this: really, none of us would be happy accepting a document with *that* much text changing after last call, without a second last call. I know you think it's just editorial stuff, and I know you think another last call will just bring up all the same issues that got set aside last time (legitimately or not). And, yet, c'mon: can you honestly say that you'd be happy if another document, one that you weren't involved in, was essentially re-written after last call? From nobody Mon Sep 1 01:28:57 2014 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 060661A0202 for ; Mon, 1 Sep 2014 01:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 94SV1jTB_cjB; Mon, 1 Sep 2014 01:28:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6A81A01EA; Mon, 1 Sep 2014 01:28:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140901082849.27285.69738.idtracker@ietfa.amsl.com> Date: Mon, 01 Sep 2014 01:28:49 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/inqSY7hOoIBI1OU_io7bLKvwiSg Subject: [saag] ID Tracker State Update Notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 08:28:52 -0000 IESG state changed to IESG Evaluation - Defer from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Mon Sep 1 02:17:06 2014 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 84DDD1A02DD; Mon, 1 Sep 2014 02:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 lHYrvaNRgukK; Mon, 1 Sep 2014 02:17:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2215B1A02D1; Mon, 1 Sep 2014 02:17:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIY10707; Mon, 01 Sep 2014 09:17:00 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 10:16:53 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" , "ipv6@ietf.org" Thread-Topic: Review request for draft-rafiee-rfc3972-bis-00.txt Thread-Index: AQHPxcV4+2LtLSfDSUyy8a1D1WgVnw== Date: Mon, 1 Sep 2014 09:16:53 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A2A436@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1UxeoLeGxh01AoZk2P31jvwveIk Subject: [saag] Review request for draft-rafiee-rfc3972-bis-00.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: Mon, 01 Sep 2014 09:17:03 -0000 Rm9sa3MsDQoNClRoaXMgaXMgYSBzaG9ydCBkcmFmdCB0byBpbXByb3ZlIENHQSBzcGVjaWZpY2F0 aW9uIChSRkMgMzk3MikuIFBsZWFzZSBzaGFyZSB5b3VyIGNvbW1lbnRzIHRvIGtub3cgd2hldGhl ciB3ZSBtaXNzZWQgc29tZXRoaW5nIG9yIHdlIGNvbnNpZGVyZWQgdGhlIHNvbHV0aW9uIHRvIGFs bCBhdHRhY2tzLg0KDQoNClRoYW5rcyAsDQpCZXN0LA0KSG9zbmllaA0KSHRtbGl6ZWQ6ICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhZmllZS1yZmMzOTcyLWJpcy0wMA0K DQoNCg== From nobody Mon Sep 1 02:27:08 2014 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 4A1B11A02DB; Mon, 1 Sep 2014 02:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 jN5Jpx2rwNHe; Mon, 1 Sep 2014 02:27:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B6D1A02D5; Mon, 1 Sep 2014 02:27:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIY11966; Mon, 01 Sep 2014 09:27:00 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 10:26:56 +0100 From: Hosnieh Rafiee To: "secauth@ietf.org" Thread-Topic: Review request- secauth - authentication and authorization - first draft Thread-Index: AQHPxcbficLM/RnRMUiwoQ+/hu2oEw== Date: Mon, 1 Sep 2014 09:26:55 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> In-Reply-To: <53FDDDA2.3070607@freeradius.org> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lGFLxJkib1IjGb-3goHyQKZDP2Q Cc: "saag@ietf.org" Subject: [saag] Review request- secauth - authentication and authorization - first draft 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, 01 Sep 2014 09:27:04 -0000 Folks, I have received a few comments offlist. I would welcome more comments if an= y. Please consider reviewing it and share your ideas to know whether or not= we considered all your thoughts or we need to work more. I would prefer to receive comments on the mailinglist rather than offlist. = Because other folks might also include something to your comments or there = might be supporters or non-supporters of certain idea. Thanks, Best, Hosnieh http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00=20 From nobody Mon Sep 1 03:53:39 2014 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 5D9601A0362; Mon, 1 Sep 2014 03:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] 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 a4T1s09QbAPD; Mon, 1 Sep 2014 03:53:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9755A1A0361; Mon, 1 Sep 2014 03:53:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3E17FBE58; Mon, 1 Sep 2014 11:53:26 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD5wSvgVLDjJ; Mon, 1 Sep 2014 11:53:26 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1C1FDBE0F; Mon, 1 Sep 2014 11:53:26 +0100 (IST) Message-ID: <54045028.2080606@cs.tcd.ie> Date: Mon, 01 Sep 2014 11:53:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20140901082838.26648.23612.idtracker@ietfa.amsl.com> In-Reply-To: <20140901082838.26648.23612.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bcMr9tYU_3ehZtaZDRBWl_UIvoI Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Barry Leiba's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 01 Sep 2014 10:53:30 -0000 Hiya, On 01/09/14 09:28, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm going to press "defer" on this, because I have concerns about the > consensus here, and because of the IGF meeting I won't have time to chase > it down and satisfy myself. Deferring is no big deal. There's nothing waiting on this that's in a rush. I do however hope that you'll now join me in fending off any further attempts to regurgitate already digested topics:-) > Primary among my concerns is this: really, none of us would be happy > accepting a document with *that* much text changing after last call, > without a second last call. I know you think it's just editorial stuff, > and I know you think another last call will just bring up all the same > issues that got set aside last time (legitimately or not). And, yet, > c'mon: can you honestly say that you'd be happy if another document, one > that you weren't involved in, was essentially re-written after last call? Bit of a multi-pronged answer, but since this is, I think, a slightly odd case, I'll give you all the prongs that I can think of right now. First, I am not happy that this draft has (needlessly IMO) required so much effort. So unhappy is the starting state, but for a different reason:-) As to the diff between -03 and -04: I'm happy that it is purely editorial - if you don't judge by the red/green colour of the diff, of what is now an 11 page draft, but read the altered text, then you'll see that -04 has some more text, along the lines suggested on the list, and is otherwise an almost paragraph-by-paragraph paraphrase of -03. If you read all the list traffic, I think you'll also agree that those changes do respect the comments received. And I'd guess that, like me, your trip through the feast of last call messages may also convince you that additional time to comment is only likely to result in additional (not all good tempered) nitpicking and also (probably increasingly less good-tempered) responses to that and to continued repetitive expression of in-the- roughness, for those who remain in the rough. I'll also note in passing that the LC was already extended once to give folks time to comment on -03 which was published at the end of the original LC. And additionally, having just checked again, I don't myself see any very important changes between -02, -03 and -04 - there are different numbers of different words in a different order, but they all say the same thing really. The above is slightly unusual, but there's another odd aspect to this draft - if one understands what is going on here, (which is a little, but not a lot, subtle) it doesn't really matter that the definition or descriptive text in the draft is at all precise. The existence of this RFC with pretty much any non-crazy descriptive text will have just as much (good, bad or indifferent) effect as any other RFC describing the same concept, no matter how polished the text in the latter might be. That is partly why what might otherwise not be considered editorial change, is purely editorial change in this case. (BTW I believe this is partly why some folks remain in the rough - they'd prefer a different RFC and not just one that defines/describes OS for an IETF readership as is the case here. And before you ask, I do not think those in the rough in that way have the same "other RFC" in mind so that's not likely to be a productive avenue of discussion.) And lastly, I fully admit to a personal preference to not cater for nitpicking and issue-regurgitation as has been seen here. I think appeasing such, irrespective of source or motive, significantly disrespects our processes and IETF participants and is something that we (for at least we==IESG) ought actively and visibly push back against, when we're convinced that's what's going on. None of that btw impugns the motives of those commenting - we all get carried away now and then, and sometimes we just feel strongly about stuff. So in yet another odd way, doing what seems easier and more process-pure (further extending the LC) would actually be less respectful of our processes, is my conclusion. So to directly answer your question: if you or another AD did something similar, I'd not be unhappy, but I would be pretty curious and would take the time to check it out, just as you're doing. Cheers, S. PS: All that said, its up to you and the other IESG folks to (dis)agree with the above and its entirely fine with me if you look stuff over and come to different conclusions. Once you've done that we'll chat about it and doing so in a couple of weeks is just as good as this week. PPS: And for folks on the saag list, as I said before, there's no need to respond here unless your response is really really necessary. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Mon Sep 1 16:17:36 2014 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 D72881A212D for ; Mon, 1 Sep 2014 16:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Xymf-afMj5In for ; Mon, 1 Sep 2014 16:17:31 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127FA1A212A for ; Mon, 1 Sep 2014 16:17:30 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 347002AB2BB; Mon, 1 Sep 2014 23:17:29 +0000 (UTC) Date: Mon, 1 Sep 2014 23:17:29 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140901231729.GS14392@mournblade.imrryr.org> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/r58Kvr6xEd8E3FYTlAGC7A_N58M Subject: Re: [saag] Review request- secauth - authentication and authorization - first draft 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: Mon, 01 Sep 2014 23:17:33 -0000 On Mon, Sep 01, 2014 at 09:26:55AM +0000, Hosnieh Rafiee wrote: > I have received a few comments offlist. I would welcome more > comments if any. Please consider reviewing it and share your ideas > to know whether or not we considered all your thoughts or we need > to work more. The draft seems to have much text in 3.1 on various flavours of authentication mechanisms at the application layer. It is not clear why these are there, if the goal is primarily to explore the requirements for an API that exposes network-layer security to the application layer. It is not clear what the purpose of section 3.2 is. Section 3.3 seems to talk about virtual network infrastructure. Is this API between the application layer and local network-layer security such as IPSEC, ... Or is it an interface to talk to network infrastructure? (Switches, Proxies, ...) The remaining sections seem too sketchy. Critically, the last paragraph of the introduction: Therefore, The purpose of this document is to reduce the security gap between end users and devices or devices to end devices during authentication and authorization where other authentication or authorization approaches are unable to address this problem easily without many pre-configurations. In other words, this API aims to assist a secure authentication and authorization for the last mile of the Internet. This document defines the problem statement and identifies the requirements for a robust easy secure authentication and authorization of nodes using a combination of network layer and application layer security approaches. seems rather unclear. Is securing the last mile an API problem? As yet, there does not seem to be very much text actually addressing the API requirements. One example requirement is to expose a channel-binding between the network layer encrypted channel, and the application data stream, which can be used in combination with higher-layer mechanisms to create an authenticated application-layer message stream out of from a network layer that provides unauthenticated encryption with integrity protection. Other requirements might include functionality to query the security state of the network layer, or control it. If I am not misreading the intended scope of the draft, it seems too early to review it, because so little is there... -- Viktor. From nobody Tue Sep 2 04:11:38 2014 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 EC4111A0109; Tue, 2 Sep 2014 04:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 fVpmRxfS-gOi; Tue, 2 Sep 2014 04:11:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693AE1A004C; Tue, 2 Sep 2014 04:11:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIZ27693; Tue, 02 Sep 2014 11:11:29 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Tue, 2 Sep 2014 12:11:23 +0100 From: Hosnieh Rafiee To: "saag@ietf.org" Thread-Topic: [saag] Review request- secauth - authentication and authorization - first draft Thread-Index: AQHPxcbficLM/RnRMUiwoQ+/hu2oE5vs2XuAgAC44GA= Date: Tue, 2 Sep 2014 11:11:22 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A2A78F@lhreml513-mbb.china.huawei.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <20140901231729.GS14392@mournblade.imrryr.org> In-Reply-To: <20140901231729.GS14392@mournblade.imrryr.org> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Nj6jicM1yPrjjESG9QN7PIpS2yg Cc: "secauth@ietf.org" Subject: Re: [saag] Review request- secauth - authentication and authorization - first draft 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, 02 Sep 2014 11:11:36 -0000 Viktor, Again thanks a lot for your comments which I really appreciated it.=20 >=20 > The draft seems to have much text in 3.1 on various flavours of > authentication mechanisms at the application layer. It is not clear > why these are there, if the goal is primarily to explore the > requirements for an API that exposes network-layer security to the > application layer. Yes, as the title of this draft also shows, the purpose is only requirement= s and use cases and still I don't plan to go through the solution space. Ho= wever, I have some ideas but I guess it makes sense to go through it after = we have an acceptable version of the requirement document. > It is not clear what the purpose of section 3.2 is. >=20 > Section 3.3 seems to talk about virtual network infrastructure. > Is this API between the application layer and local network-layer > security such as IPSEC, ... Or is it an interface to talk to network > infrastructure? (Switches, Proxies, ...) No, this API is inside each node and handles the secure authentication betw= een two devices that there can be user behind one of these device or there = can be also another device.=20 And the infrastructure can be switches, proxy servers, etc. Please consider the following cases Authentication /authorization (for short: Auth2) of a user to a device (thi= s is of course not possible without an application. So to summarize it, it = is Auth2 of the application1 to application2 where application 2 is on anot= her node located on different network or the same network) So for this use case scenario,=20 Virtualization falls into the category of Auth2 of device to device. This i= s , of course, via some applications but the differences is that there is n= o human or user in between and all the things are done automatically betwee= n two devices that can be on a same network or on different networks.=20 This is like a policy enforcer protocol wants to setup authentication and a= uthorization Now about this Auth2 in detail for second scenario that is virtualization (= I guess this was the confusing part. right?) Virtual device (VD) x wants to add a new rule in virtual device y. VD x nee= ds to authenticate VD y and then authorize it before it allows it to add or= modify any resources on VD y. VD x uses secauth api and sends authenticati= on request to VD y, based on secauth configuration, it first uses a network= layer authentication to create the first level of trust. After VD y uses s= ecauth and authenticates VD x, it authorizes VD x to use some resources or = modify a resources on VD y. This step can be handled by other mechanisms (l= ike Oauth) or still can be handled by secauth because the first point of tr= ust was the main purpose of secauth and the other parts can be handled by o= ther protocols or secauth as well. Such as starting a secure channel to enc= rypt all data, etc. =20 Do you think my example is clear?=20 Secauth might also use other mechanisms to create this first trust efficien= tly.=20 This is what I tried to explain or expand the virtualization section.=20 > Critically, the last paragraph of the introduction: > seems rather unclear. Is securing the last mile an API problem? Not an API problem, but the current problems with current protocols and the= purpose is to eliminate this problem or eliminate the gap in first point o= f trust. > One example requirement is to expose a channel-binding between the > network layer encrypted channel, and the application data stream, which > can be used in combination with higher-layer mechanisms to create an > authenticated application-layer message stream out of from a network > layer that provides unauthenticated encryption with integrity > protection. Do you mean I need to go to more detail about requirements? Isn't it consid= ered as a use case scenario that how the things need to work? I mean shall = I expand the use case section or requirement section? > Other requirements might include functionality to query the security > state of the network layer, or control it. >=20 > If I am not misreading the intended scope of the draft, it seems too > early to review it, because so little is there... Thanks again, Best, Hosnieh From nobody Tue Sep 2 21:03:50 2014 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 0EDD51A89C6; Tue, 2 Sep 2014 21:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 5FDnL7VlIYvr; Tue, 2 Sep 2014 21:03:46 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012A81A89C3; Tue, 2 Sep 2014 21:03:45 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s8343gYw027340; Tue, 2 Sep 2014 21:03:42 -0700 Received: from sc-owa04.marvell.com ([199.233.58.150]) by mx0a-0016f401.pphosted.com with ESMTP id 1p5m720490-5205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 02 Sep 2014 21:03:40 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA04.marvell.com ([fe80::e56e:83a7:9eef:b5a1%16]) with mapi; Tue, 2 Sep 2014 21:02:56 -0700 From: Paul Lambert To: Hosnieh Rafiee , "secauth@ietf.org" Date: Tue, 2 Sep 2014 21:02:55 -0700 Thread-Topic: Review request- secauth - authentication and authorization - first draft Thread-Index: AQHPxcbficLM/RnRMUiwoQ+/hu2oE5vuxkdA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_03:2014-09-02,2014-09-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409030043 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-ejnQtPGCecuQjZnmwQA58KvkNw Cc: "saag@ietf.org" Subject: Re: [saag] Review request- secauth - authentication and authorization - first draft 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, 03 Sep 2014 04:03:48 -0000 ]-----Original Message----- ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Hosnieh Rafiee ]Sent: Monday, September 01, 2014 2:27 AM ]To: secauth@ietf.org ]Cc: saag@ietf.org ]Subject: [saag] Review request- secauth - authentication and ]authorization - first draft ] ]Folks, ] ]I have received a few comments offlist. I would welcome more comments if ]any. Please consider reviewing it and share your ideas to know whether ]or not we considered all your thoughts or we need to work more. I find the abstract and purpose of the document confusing. It's hard to tell purpose of the requirements. "... use cases and requirements for secure authentication in other layers above the network layer ..." Not sure why layers matter in the abstract for AuthN/AuthZ services. "... and the use of network layer security approaches for this purpose. ..." The first part excludes network layer and=20 now you include network layer. " 3.1. Authentication/Authorization of a User to a Device" Not sure why this would be in scope since the user is not an 'application'.=20 This is also not a well formed use case (e.g. a banking application that needed to validate that a user had direct control over a application might be a viable use case) " 3.1.1. Biometric Authentication" This is not a use case, it's a mechanism. " 3.1.5. NAT Scenario" Useful use case for network layer ... Not clearly articulated why it's interesting. Not so important above layer three. Not clear about scope of this document. " 3.1.6. Valid IP address" Does not make sense in section 3.1 Not really the right term for the scenario. Not really a use case, but one possible addressing Situation. Use cases might beter include users: - home user behind firewall - home gateway with static IP address (valid) - home IoT widget with IPv6 based on device MAC address (privacy issues) - home IoT widget with IPv6 based on Ephemeral MAC address - etc " 3.3. Authentication and Authorization of Virtual Devices" Not clear if this is in scope for IETF work. Internal security of Virtualized services is not apparent over-the-wire. A virtual server is typically indistinguishable from a non-virtual server. ] ]I would prefer to receive comments on the mailinglist rather than ]offlist. Because other folks might also include something to your ]comments or there might be supporters or non-supporters of certain idea. Draft is a bit rough at the moment. Clarity in abstract and purpose=20 would be a good starting point. Paul ] ]Thanks, ]Best, ]Hosnieh ]http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00 ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Wed Sep 3 04:18:30 2014 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 2DD991A86FE; Wed, 3 Sep 2014 04:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 83wKtVNwyrv1; Wed, 3 Sep 2014 04:18:24 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 CDBE21A00E1; Wed, 3 Sep 2014 04:18:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 98C2A5660916; Wed, 3 Sep 2014 11:18:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPcj3BodvMBB; Wed, 3 Sep 2014 13:17:51 +0200 (CEST) Received: from kopoli (p5B343C97.dip0.t-ipconnect.de [91.52.60.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 8A4495660908; Wed, 3 Sep 2014 13:17:51 +0200 (CEST) From: "Hosnieh Rafiee" To: References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> Date: Wed, 3 Sep 2014 13:17:48 +0200 Message-ID: <000101cfc768$b26d56b0$17480410$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIg2iDjW82G5bjHhRmYPmeon6KLlwKyZQhkAfvrc1sB0iolhpsZEldQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UumLKL2cjjhENtIz82TKrrZIgks Cc: saag@ietf.org Subject: Re: [saag] Review request- secauth - authentication and authorization - first draft 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, 03 Sep 2014 11:18:27 -0000 Hi Paul, Thanks a lot for your comments and suggestions. I will consider them all in next version. Please see my responses inline... > I find the abstract and purpose of the document confusing. > It's hard to tell purpose of the requirements. I kept the abstract so short. But if it is needed I would expand it. > "... use cases and requirements for secure > authentication in other layers above the network layer ..." > Not sure why layers matter in the abstract for AuthN/AuthZ services. > > "... and the use of network layer security approaches > for this purpose. ..." > > The first part excludes network layer and now you include network layer. You are right. I guess it is wording problem. The purpose is to use Network layer approaches as means of authentication in other layers. This network layer approaches also can combine with other available approaches. For instance for the start, the authentication is network layer and after the establishment of this trust, it can be application layer or user based password authentication or token based to authorize this user to access to certain resources. Like two level authentication and authorization. > " 3.1. Authentication/Authorization of a User to a Device" > Not sure why this would be in scope since the user is not an 'application'. > This is also not a well formed use case > (e.g. a banking application that needed > to validate that a user had direct control over a application might be a viable > use case) > > > > " 3.1.1. Biometric Authentication" > This is not a use case, it's a mechanism. > > " 3.1.5. NAT Scenario" > Useful use case for network layer ... > Not clearly articulated why it's interesting. > Not so important above layer three. > Not clear about scope of this document. I would like to remove the requirements for CA for each single node. CA might be useful for many cases but not when we supposed to use it for each single user and single node. So the purpose is to remove CAs and also automation when we plan not to use CA. because by removing CA, the problem would be the establishment of trust. So, now the purpose is to provide this trust with less efforts. Since most spoofing attacks happens in network layer, we aim to prevent this attack in this layer. Please consider that the aim is not only the authentication and authorization of a user to access some resources but also a node to update, or modify something on another node. This is why the cases like proxy servers are important. Since we are talking about network layer approaches to easily avoid IP spoofing and other kinds of spoofing problems, then NAT MIGHT cause a problem and that was a reason that I considered a scenario where one of our nodes are behind NAT. Do you think it is clear now? > " 3.1.6. Valid IP address" > Does not make sense in section 3.1 > Not really the right term for the scenario. > Not really a use case, but one possible addressing Situation. Ok, then change it to something else. > Use cases might beter include users: > - home user behind firewall > - home gateway with static IP address (valid) > - home IoT widget with IPv6 based on device MAC address (privacy issues) > - home IoT widget with IPv6 based on Ephemeral MAC address > - etc Thanks for the suggestion. Ok, I will consider them. > > " 3.3. Authentication and Authorization of Virtual Devices" > Not clear if this is in scope for IETF work. Internal security of Virtualized > services is not apparent over-the-wire. A virtual server is typically > indistinguishable from a non-virtual server. > > > > Draft is a bit rough at the moment. Clarity in abstract and purpose would be a > good starting point. Ok I will try to address them and will prepare next version. Best, Hosnieh From nobody Thu Sep 4 01:16:26 2014 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 8A56E1A004D; Thu, 4 Sep 2014 01:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.856 X-Spam-Level: X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 miG08cE4UMq7; Thu, 4 Sep 2014 01:16:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 3BBCC1A000A; Thu, 4 Sep 2014 01:16:23 -0700 (PDT) Received: from [217.140.96.21] by 3capp-gmx-bs62.server.lan (via HTTP); Thu, 4 Sep 2014 10:16:20 +0200 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: lwip@ietf.org, saag@ietf.org, dtls-iot@ietf.org Content-Type: text/html; charset=UTF-8 Date: Thu, 4 Sep 2014 10:16:20 +0200 Importance: normal Sensitivity: Normal References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:rlGqsGr4yk9pnEfjifofme9kGGVBNhKD+0q1rZ/wJNM VrAr8qPiMr4FKtsF/OyxptpUR9EF4s3PlPwk9TW1F9ifW4Q/ue bAfFfgq/xU3xdtmh1FyALnmPhI1VTI+iT+/DnQv8LudHYY36Qw ANeeH/krOtl5vaq2TCsuKAf/mZn2cqPGn4UthJntB6zQ1nmauS sR+ghHo3MCYhf/k0TLGiM/4z+8tgeYsjdpRm3iAeXnLS1jvmRZ wAfv9U9CjSONBuBGHuuDHkdCSdpc6uFqoYQy2gkn0mLlG3IZKp hYrGlA= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3CFwKOZqOXI7BbVpdzvDIwVnIiw Subject: [saag] Fw: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" --> *** Friday, 12th September *** 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, 04 Sep 2014 08:16:24 -0000
FYI
 
Gesendet: Donnerstag, 04. September 2014 um 10:12 Uhr
Von: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
An: ace@ietf.org
Betreff: [Ace] Webex Conference Call about "How to Select Hardware for IoT Systems?" --> *** Friday, 12th September ***
The Webinar will take place on Friday, 12th September 1pm BST.
 
As soon as I get access to the Webex credentials for the ACE working group setup I will distribute it. 
 
Ciao
Hannes
 
-------- Forwarded Message --------
Subject: [Ace] Webex Conference Call about "How to Select Hardware for
IoT Systems?"
Date: Sat, 23 Aug 2014 14:24:51 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Ace@ietf.org <Ace@ietf.org>

Hi all,

Various groups in the IETF currently standardize technology for use with
constrained devices and the choice of hardware impacts the design of
Internet of Things (IoT) systems. To provide guidance RFC 7228
"Terminology for Constrained-Node Networks" defines three classes of
devices depending on their RAM and flash memory size. Class 0
characterizes devices that have less than 10 KiB of RAM and less than
100 KiB of flash memory and RFC 7228 adds "... most likely they will not
have the resources required to communicate directly with the Internet in
a secure manner." For others even class 2 with ~ 50 KiB of RAM and ~ 250
KiB of flash memory is too constrained.

With the increasing commercial interest in IoT the question about a
reasonable hardware configuration surfaces again and again. At IETF#90 I
offered to bring a hardware expert along. Peter Aldworth, a hardware
engineer with more than 19 years of experience, will lead the discussion
at an upcoming webinar.

Please indicate your availability here:
http://moreganize.com/bzTrVxhqaHp

Ciao
Hannes
 
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
From nobody Mon Sep 8 12:58:55 2014 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 B26391A0379; Mon, 8 Sep 2014 12:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 9VxnLa-HsD73; Mon, 8 Sep 2014 12:58:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6031A034B; Mon, 8 Sep 2014 12:58:47 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 32FF050AA3; Mon, 8 Sep 2014 15:58:45 -0400 (EDT) Message-ID: <540E0A56.7060301@seantek.com> Date: Mon, 08 Sep 2014 12:58:14 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: pkix@ietf.org, saag@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090003050207050507080609" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZopUQzLeEUqHPksbipWAObnkE3c Subject: [saag] New Version Notification for draft-seantek-certfrag-00.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: Mon, 08 Sep 2014 19:58:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090003050207050507080609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello PKIX and SAAG lists: Based on discussions had at IETF 90, I have written up a new=20 Internet-Draft to define URI fragment identifiers for certificates. The=20 proposal is very simple, as there are only a limited number of=20 well-defined PKIX certificate parts. This text is a spinoff of draft-seantek-certspec, since the fragment=20 definitions depend on the media type (application/pkix-cert), not on the = URI scheme or other parts. Feedback is appreciated. Sean ************************* A new version of I-D, draft-seantek-certfrag-00.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-certfrag Revision: 00 Title: URI Fragment Identifiers for the application/pkix-cert Media Type= Document date: 2014-09-08 Group: Individual Submission Pages: 4 URL:=20 http://www.ietf.org/internet-drafts/draft-seantek-certfrag-00.txt Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/ Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-00 Abstract: This memo describes Uniform Resource Identifier (URI) fragment identifiers for PKIX certificates, which are identified with the Internet media type application/pkix-cert. =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms090003050207050507080609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDkwODE5NTgxNFowIwYJKoZIhvcNAQkEMRYEFANLYNoms5GjA6gI pFhoQJCzHlbhMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQCvVPt3N0ibfhDHyn44bOspaluqjWIg +uz7DhDs36WkPRu5f0yKyRuhoi7EFg60ZFkyYfF4Igak/q8dhjHtbQIgzeicMNx4w3V0biQR AzDa76JxWDhcX9mdPjAkexjfkM+wok5Kqw7I3r93Y9JXvOohcZqfR4h1ZMaUaG+vG7yJuylw bUrRvwe5MXKdE39gm5O5OyjXTX1Sg0Mgfa4q1ID9X006WJ0YgRvqtF/vG3v0ATck45vzcE7q rzyJPGOh828I9hERpvHSVlpsa6/1eEoZCtKfSyexI4Q05oAtq8gkAUZqyltmPx9W5Blwqf9/ vr+qsPfLgbIkQrEkZ3Vt8UWSAAAAAAAA --------------ms090003050207050507080609-- From nobody Thu Sep 11 07:45:38 2014 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 ED43E1A00BB; Thu, 11 Sep 2014 07:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 inaj0WYpBqXH; Thu, 11 Sep 2014 07:45:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 518691A02DF; Thu, 11 Sep 2014 07:45:33 -0700 (PDT) Received: from [192.168.10.162] ([207.47.25.82]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lu3J4-1YTEL70zaw-011RLy; Thu, 11 Sep 2014 16:45:31 +0200 Message-ID: <5411B588.9090500@gmx.net> Date: Thu, 11 Sep 2014 16:45:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: saag , "cfrg@irtf.org" References: <5411B3B3.6090709@gmx.net> In-Reply-To: <5411B3B3.6090709@gmx.net> OpenPGP: id=4D776BC9 X-Forwarded-Message-Id: <5411B3B3.6090709@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MErKVJMqCxT6I1jXvonaQFMkAL8WPCHN4" X-Provags-ID: V03:K0:XX9utD/q8smsk/MS28Toehx2ic5Du3Wb10FYeKyOPOIu54Fi5YY W0FEt+FX3fy80mMyaWS8j4qfRIIZyZOP2pxHb7EavDFOmsTS/Dr33hby/a3BrsKRQkUYZdO 8VSyk3lzBKU2upPMtAvnIXv8/txaoN3c5BDWAqN1T/foEX3AhPqVw9yiL1Vnb2FZ7FaE6TO 9Fbe4mVh7ShgdZ79ySAeA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9QjV64QBBeq5usbnys1y8d6DCZY Subject: [saag] Conference call about " How to Select Hardware for Internet of Things Systems?" (Friday, 12th September) 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, 11 Sep 2014 14:45:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MErKVJMqCxT6I1jXvonaQFMkAL8WPCHN4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, as part of our work in the recently formed ACE working group we are often facing the question about hardware requirements for Internet of Things systems and hence we have scheduled a conference call to discuss this topic. My co-worker Peter Aldworth from ARM will give a short presentation tomorrow. Since the topic of performance and hardware requirements also surfaces in other security groups I thought you might want to be aware of our conference call tomorrow. Here is my earlier announcement with a bit more information: http://www.ietf.org/mail-archive/web/ace/current/msg00825.html Ciao Hannes -------- Forwarded Message -------- Subject: [Ace] WebEx meeting info: How to Select Hardware for IoT Systems= ? Date: Thu, 11 Sep 2014 16:37:39 +0200 From: Hannes Tschofenig To: Ace@ietf.org Hi all, here is the webex information for our conference call tomorrow. We am looking forward to an interesting discussion. Ciao Hannes & Kepeng ----------------------- *How to Select Hardware for IoT Systems?* Friday, September 12, 2014 1:00 pm | GMT Summer Time (London, GMT+01:00) | 1 hr Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=3Dm1b9d0bcee385ebb169b4fb5631b7ab5= 3 Meeting number: 642 573 373 Meeting password: foobar Join by phone: +1-877-668-4493* Call-in toll free number (US/Canada) +1-650-479-3208* Call-in toll number (US/Canada) Access code: 642 573 373 Toll-free calling restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=3Dm5e23b4523c843310775c5e9c55f2f8e= 4 Can't join the meeting? Contact support: https://ietf.webex.com/ietf/mc --MErKVJMqCxT6I1jXvonaQFMkAL8WPCHN4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUEbWIAAoJEGhJURNOOiAtVt0H/Ru/1DQITdts00otgX370o0W egkD23F8y0c4wSxVfgYbabPI2VYSVKNQZhwP6Ud94Y5i56jGgbtep+IiqqmwsDYY WyS5xl0LtamdMoBnsr55jnIP4mxmWzxbeOgAHW2nP6fJADZGLM4Ysz118LFGCFei UH9ENDz+mxGrLfJ/V4R8kMpOEbAQ704QsIHyH5bKrpF7Ue5p9wi7wPtasriyoW3A 54+LG1jVv03tUwIXW1zs0xBkRc/xIbRxq+cLZwumHVrdz6nSg0vx+hoa3FXMzvIB uw3s9nhOLiajJ6V8UOuKXiqErWynNlnDBXHqTnEQbaUoB9vsaO2vycYfG+hz+2g= =MBB5 -----END PGP SIGNATURE----- --MErKVJMqCxT6I1jXvonaQFMkAL8WPCHN4-- From nobody Thu Sep 11 08:53:29 2014 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 8892D1A896A for ; Thu, 11 Sep 2014 08:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74uNwd5Flj_J for ; Thu, 11 Sep 2014 08:53:24 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70FE81A0410 for ; Thu, 11 Sep 2014 08:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2261; q=dns/txt; s=iport; t=1410450804; x=1411660404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vayhSr/hV/ImYmwLOI9bxHXPlGZwAZtTAnM00sgk4x4=; b=bwleNqpzsjftLQu9QYtbgqzLUzSd9HzfpF/d9X5W8Y9j3EWOkN4PH2Gt Y5VcytkUaly/kMu9Mljv29c2cYd4eC3ESBZ4aR1CeP5MQhX0bVyxRyYOi DUHRYQNzOtgm0l6MHws/yFvV3Q5V5bWLcmcQZbHtY71FqV8zCg7jRAr1u A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAPDEEVStJA2N/2dsb2JhbABFFwODDVNXBMg6DIdLAYERFniEAwEBAQIBAQEBAWMCBgsFCQICAQgRAwECFQQLAQobDAsdBwECAQMOBQmIJQMJCA02rkSQAAEXBI0cgVkDAQELEQgbEAIFAgQLB4MXgR0Fhh2LLIQwhwOVOYIbcVVsAYEOOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="scan'208";a="77061795" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 11 Sep 2014 15:53:23 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8BFrLn7030485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 15:53:22 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.49]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 10:53:21 -0500 From: "Mark Baugher (mbaugher)" To: Hannes Tschofenig Thread-Topic: [saag] Conference call about " How to Select Hardware for Internet of Things Systems?" (Friday, 12th September) Thread-Index: AQHPzc8QOFZUqOUj702Y0d4HSGoNEpv8aTaA Date: Thu, 11 Sep 2014 15:53:20 +0000 Message-ID: References: <5411B3B3.6090709@gmx.net> <5411B588.9090500@gmx.net> In-Reply-To: <5411B588.9090500@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.210] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0378F4D82EB0164696300229E280C3AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/jr9_l2btFsMHq-x9RLBCgBumKbI Cc: "cfrg@irtf.org" , saag Subject: Re: [saag] Conference call about " How to Select Hardware for Internet of Things Systems?" (Friday, 12th September) 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, 11 Sep 2014 15:53:26 -0000 Hi, Did you record the presentation by any chance? thanks, Mark On Sep 11, 2014, at 7:45 AM, Hannes Tschofenig = wrote: > Hi all, >=20 > as part of our work in the recently formed ACE working group we are > often facing the question about hardware requirements for Internet of > Things systems and hence we have scheduled a conference call to discuss > this topic. My co-worker Peter Aldworth from ARM will give a short > presentation tomorrow. >=20 > Since the topic of performance and hardware requirements also surfaces > in other security groups I thought you might want to be aware of our > conference call tomorrow. >=20 > Here is my earlier announcement with a bit more information: > http://www.ietf.org/mail-archive/web/ace/current/msg00825.html >=20 > Ciao > Hannes >=20 > -------- Forwarded Message -------- > Subject: [Ace] WebEx meeting info: How to Select Hardware for IoT Systems= ? > Date: Thu, 11 Sep 2014 16:37:39 +0200 > From: Hannes Tschofenig > To: Ace@ietf.org >=20 > Hi all, >=20 > here is the webex information for our conference call tomorrow. > We am looking forward to an interesting discussion. >=20 > Ciao > Hannes & Kepeng >=20 > ----------------------- >=20 > *How to Select Hardware for IoT Systems?* > Friday, September 12, 2014 > 1:00 pm | GMT Summer Time (London, GMT+01:00) | 1 hr >=20 > Join WebEx meeting > https://ietf.webex.com/ietf/j.php?MTID=3Dm1b9d0bcee385ebb169b4fb5631b7ab5= 3 >=20 > Meeting number: 642 573 373 > Meeting password: foobar >=20 >=20 > Join by phone: > +1-877-668-4493* Call-in toll free number (US/Canada) > +1-650-479-3208* Call-in toll number (US/Canada) > Access code: 642 573 373 >=20 > Toll-free calling restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf >=20 >=20 > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=3Dm5e23b4523c843310775c5e9c55f2f8e= 4 >=20 > Can't join the meeting? Contact support: > https://ietf.webex.com/ietf/mc >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Sep 12 04:39:57 2014 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 388981A06F9 for ; Fri, 12 Sep 2014 04:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 EXve8EE-15Wm for ; Fri, 12 Sep 2014 04:39:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ECA161A06EC for ; Fri, 12 Sep 2014 04:39:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5C446BE35 for ; Fri, 12 Sep 2014 12:39:52 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXzeJsNh_RtR for ; Fri, 12 Sep 2014 12:39:52 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3ADD4BE0F for ; Fri, 12 Sep 2014 12:39:52 +0100 (IST) Message-ID: <5412DB89.8030300@cs.tcd.ie> Date: Fri, 12 Sep 2014 12:39:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "saag@ietf.org" References: <20140911212902.3522.94185.idtracker@ietfa.amsl.com> In-Reply-To: <20140911212902.3522.94185.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140911212902.3522.94185.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Gt2Gne_vLdIzYcI-25dxmEkPSuQ Subject: [saag] Fwd: New Non-WG Mailing List: vot -- Vectors of Trust discussion 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: Fri, 12 Sep 2014 11:39:55 -0000 Hiya, This is a new list some folks here might care about. Cheers, S. -------- Forwarded Message -------- Subject: New Non-WG Mailing List: vot -- Vectors of Trust discussion list Date: Thu, 11 Sep 2014 14:29:02 -0700 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: olshansky@isoc.org, leifj@sunet.se, vot@ietf.org A new IETF non-working group email list has been created. List address: vot@ietf.org Archive: http://www.ietf.org/mail-archive/web/vot/ To subscribe: https://www.ietf.org/mailman/listinfo/vot Purpose: Since the publication of RFC 2527 there have been several attempts to standardize technology-independent frameworks for describing the concerns that go into a determination of inter-organizational and transactional trust. Notable examples include NIST SP 800-63, The Kantara Identity Assurance Framework (historically originating from the Liberty Alliance and Electronic Authentication Partnership) and ISO 29115. These documents have been profiled and reworked a number of times in the last few years. The vot@ietf.org list is for discussion of a common set of baseline "vectors of trust": common, orthogonal aspects of organization, technology and policy that help to determine the level of assurance that can be placed in a deployment of digital identity technology. Work will draw on deployment experience related to web identity technology (eg SAML, OAUTH and OpenID Connect) as well as experience with current state of the art in identity assurance. For additional information, please contact the list administrators. From nobody Sat Sep 13 23:12:38 2014 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 1722F1A0248; Sat, 13 Sep 2014 23:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 68Ktg-J0Qfyx; Sat, 13 Sep 2014 23:12:33 -0700 (PDT) Received: from sender1.zohomail.com (sender1.zohomail.com [74.201.84.155]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF351A0243; Sat, 13 Sep 2014 23:12:33 -0700 (PDT) Received: from [0.0.0.0] (223.255.139.203 [223.255.139.203]) by mx.zohomail.com with SMTPS id 1410675151853974.9787642891206; Sat, 13 Sep 2014 23:12:31 -0700 (PDT) Message-ID: <541531CD.3000104@checkssh.com> Date: Sun, 14 Sep 2014 14:12:29 +0800 From: John Leo User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: sshmgmt@ietf.org, saag@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ZohoMailClient: External X-Zoho-Virus-Status: 2 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UbzXS1w9OoPdU9ZcZbY3eDlKu9Y Subject: [saag] SSH host key fingerprint - through HTTPS 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, 14 Sep 2014 06:12:35 -0000 This tool displays SSH host key fingerprint - through HTTPS. SSH is about security; host key matters a lot here; and you can know for sure by using this tool. It means you know precisely how to answer this question: The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9. Are you sure you want to continue connecting (yes/no)? https://checkssh.com/ We hackers don't want to get hacked. :-) SSH rocks - when host key is right. Enjoy! Best Wishes, From nobody Sun Sep 14 02:54:55 2014 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 026E11A02F1 for ; Sun, 14 Sep 2014 02:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 bmGnV2KWKR6C for ; Sun, 14 Sep 2014 02:54:51 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 A62E11A0301 for ; Sun, 14 Sep 2014 02:54:51 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 01D4C5660900; Sun, 14 Sep 2014 09:54:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFX-snWAsJ7u; Sun, 14 Sep 2014 11:54:18 +0200 (CEST) Received: from kopoli (p5B340FDD.dip0.t-ipconnect.de [91.52.15.221]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 8140656608FF; Sun, 14 Sep 2014 11:54:18 +0200 (CEST) From: "Hosnieh Rafiee" To: "'John Leo'" , References: <541531CD.3000104@checkssh.com> In-Reply-To: <541531CD.3000104@checkssh.com> Date: Sun, 14 Sep 2014 11:54:15 +0200 Message-ID: <000c01cfd001$d9079050$8b16b0f0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGLAotNeNKimDBRMdygcOwgxEdnv5yJ+50A Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/saag/xAsF36xk9S3crAKTbzpsYCmW3hk Subject: Re: [saag] SSH host key fingerprint - through HTTPS 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, 14 Sep 2014 09:54:53 -0000 > > This tool displays SSH host key fingerprint - through HTTPS. > > SSH is about security; host key matters a lot here; and you can know for sure > by using this tool. It means you know precisely how to answer this question: > The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. > RSA key fingerprint is > a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9. > Are you sure you want to continue connecting (yes/no)? > > https://checkssh.com/ > > We hackers don't want to get hacked. :-) SSH rocks - when host key is right. > Enjoy! > I did not get your idea and what is it used for.. SSH protocol stores the key in the client after first connection. This kinds of application is only useful when your ssh server supports a valid certifications. Otherwise you manually entered this value in your site or trust the xx server in first point of connection. This is the same as what original ssh protocol does. If you are an attacker and being scared of being hacked, you can manually introduce the key of target server to your client and then no worry of interception... And if you are an attacker you never trust the third party website for this purpose as well! Best, Hosnieh From nobody Mon Sep 15 03:31:57 2014 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 338C61A04F1; Mon, 15 Sep 2014 03:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 0VI4NsQGvdzD; Mon, 15 Sep 2014 03:31:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 557021A02A3; Mon, 15 Sep 2014 03:31:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 03:31:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DMGt-7twEysMY3sNAm4raRAMMtU Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 10:31:49 -0000 Kathleen Moriarty has entered the following ballot position for draft-dukhovni-opportunistic-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this draft, Viktor. I have some suggested text to update a few sentences that I would like you to consider. Bottom of page 2, suggested text edit to clarify meaning on the last sentence: Change from: Protection against active attacks requires authentication. The ability to authenticate any potential peer on the Internet requires an authentication mechanism that encompasses all such peers. No IETF standards for authentication meet this requirement. To: Protection against active attacks requires authentication. The ability to authenticate any potential peer on the Internet requires an authentication mechanism that encompasses all such peers. No IETF standards for authentication scales as needed and have been deployed widely enough to meet this requirement. on page 3, I recommend updates to the 2nd and third sentences to more correctly describe the issue with CAs (it's not just one that we all need to trust) change from: With so many certification authorities, which not everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA. Without a mutually trusted CA, authentication fails, leading to communications failure in protocols that mandate authentication. To: With so many certification authorities, which not everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA from their respective lists of trusted CAs. Without a mutually trusted CA, authentication fails, leading to communications failure in protocols that mandate authentication. For the terminology section, I do like that OS is defined in the introduction and saw that many provided feedback asking for that to be done. Thanks for making the change. Should there also be a pointer from the terminology section back to section 1 for the definition of OS? Security Considerations section: I'd be happier if the first sentence had a pointer to section 3 so there is context to the statement. Perhaps change from: OS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or cleartext. To: OS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or cleartext (see Section 3. Opportunistic Security Design Principles). Or something similar just to make the point that the purpose of OS is to offer another option between authenticated and encrypted and cleartext as opposed to just saying they are all supported. Side note: Thank you for your work on this draft and partaking in the many discussion threads about the contents of the draft. The discussion on this draft were heated at times and I would have preferred to see more detailed responses to the list on *some* of the threads, those which offered direct suggestions. I think that could have helped the overall tone and interactions for a least a few of the commenters. Some reviewers put in considerable time helping to revise the draft, Steve Kent in particular, and that is very much appreciated. I do think the draft is good enough, but I would like to see my comments addressed to clarify a few more points. From nobody Mon Sep 15 07:59:57 2014 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 19A1E1A036B; Mon, 15 Sep 2014 07:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, 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 fggE1euX7K7N; Mon, 15 Sep 2014 07:59:49 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7061A0363; Mon, 15 Sep 2014 07:59:49 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-178.dsl.dynamic.fusionbroadband.com [142.254.17.178]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s8FExh7D089359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Sep 2014 07:59:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-178.dsl.dynamic.fusionbroadband.com [142.254.17.178] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 07:59:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Kk8lw9-bLZTi-QYzSdNL0G0VHtw Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 15 Sep 2014 14:59:50 -0000 Thanks for the comments. Those all seem reasonable and within the scope = of the rough consensus during IETF Last Call. Viktor will collect these = and other IESG comments for a new draft to be posted after the IESG = telechat. --Paul Hoffman= From nobody Mon Sep 15 08:26:02 2014 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 0408F1A1F20; Mon, 15 Sep 2014 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 UL96Fkd8y_Po; Mon, 15 Sep 2014 08:25:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0286C1A03C2; Mon, 15 Sep 2014 08:23:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJM09995; Mon, 15 Sep 2014 15:23:17 +0000 (GMT) Received: from LHREML513-MBX.china.huawei.com ([10.201.4.199]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Mon, 15 Sep 2014 16:22:33 +0100 From: Hosnieh Rafiee To: Paul Lambert , Viktor Dukhovni Thread-Topic: Review request- secauth - authentication and authorization - second draft Thread-Index: AQHP0Pjem6xKx/YzMUuAvU7OwT31FA== Date: Mon, 15 Sep 2014 15:22:32 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A351FE@lhreml513-mbx> References: <814D0BFB77D95844A01CA29B44CBF8A7A29685@lhreml513-mbb.china.huawei.com> <53FDDDA2.3070607@freeradius.org> <814D0BFB77D95844A01CA29B44CBF8A7A2A44F@lhreml513-mbb.china.huawei.com> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EDFD@SC-VEXCH2.marvell.com> <000101cfc768$b26d56b0$17480410$@rozanak.com> In-Reply-To: <000101cfc768$b26d56b0$17480410$@rozanak.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0atFohhnr_ASDdwrppXe5mP2u6k Cc: "secauth@ietf.org" , "saag@ietf.org" Subject: [saag] Review request- secauth - authentication and authorization - second draft 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, 15 Sep 2014 15:25:59 -0000 Hello, I have revised the secauth requirement and use case draft. I would apprecia= te your inputs on this new version. I am going to upload after receiving more feedback The current pre-upload version can be found here: < http://editor.rozanak.com/show.aspx?u=3DAZ6AA4BFD809BB71B2544CTAM > @Paul, Viktor: would you please check to see whether the document is clear = and satisfy the changes you have asked. @folks: I welcome more comments before uploading new version. Please share = your inputs on editorial, document organization or technical. Thanks, Best, Hosnieh From nobody Mon Sep 15 10:57:42 2014 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 57C5D1A6F7E; Mon, 15 Sep 2014 10:57:39 -0700 (PDT) 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 23Fft4Qo-jax; Mon, 15 Sep 2014 10:57:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3FC1A6F1E; Mon, 15 Sep 2014 10:13:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140915171334.989.63043.idtracker@ietfa.amsl.com> Date: Mon, 15 Sep 2014 10:13:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/P8TUbGVa5wmNcc5IVa-_ePHO2L4 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Adrian Farrel's Abstain on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:57:39 -0000 Adrian Farrel has entered the following ballot position for draft-dukhovni-opportunistic-security-04: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It is good and helpful, in my opinion, for the IETF to give an explanation of Opportunistic Security and advocate its use. The data tracker currently shows "Consensus: Unknown" and I think that is actually a fair representation of the state of affairs. It is, however, not a state in which we can publish an IETF Stream RFC. Having read a lot of the email thread resulting from IETF last call and looked at the changes in the last few revisions I conclude that there is general support for the technical content of this document, but that there are a good number of unaddressed issues with the development and presentation of that content. It may be true that addressing those points would not make a substantive difference to the technical ideas in the document, but that does not mean that the document would not be improved by attentive work. At the moment I am sufficiently unclear on the consensus for the publication of this document to be either able to place a Discuss on the absence of consensus or to be able to ballot No Objection. Hence this Abstain. I wish more work had been / would be done to build consensus or that the document was advanced either as "published without consensus" or on the Independent Stream. ========== I have spent too long hanging around with sales staff and this has made me over-sensitive to the use of language that smells of marketing. I apologise for any over-reaction on my part, but I presume that the purpose of publishing the document is to deliver a useful and clear statement, so I think that polishing might not be a waste of time. If I was entering this Comment as part of IETF last call I would expect a reasonable discussion of the cost/benefit of not changing the text to address my thoughts. But, obviously, I am not. Furthermore, I am not raising these points as Discusses so you can work through them with your shepherding AD and ignore me if you think that I am wrong or that the effort is not worth the results. - - - - Abstract... Protocol designs based on Opportunistic Security remove barriers to the widespread use of encryption on the Internet by using encryption even when authentication is not available So, this says "remove barriers to X by using X". I think there is probably something additional you need to say before this sentence. For example, "Most approaches to the use of encryption on the Internet depend on the use authentication to foo. This makes encryption unattractive because bar." --- Introduction Broadly speaking, Opportunistic Security (OS) is a pragmatic risk management approach. "pragmatic" is redundant in the description of "risk management". "...approach" to what? --- Introduction With Opportunistic Security, one applies the tools at hand This implies to me that no changes or modifications to protocols are needed to achieve OS. I don't believe that is true. --- The definition presented in Section 1 is OK as far as it goes, but isn't it missing also the existence of the capability in the protocol itself? Isn't a fundamental part of OS that the operation of encryption can be without manual keying and therefore without the configuration of security adjacencies? I think that what is missing from this document, and possibly from this definition, is a description of why security (specifically encryption) is not widely used in the Internet today. It is also a little questionable to me what is "opportunistic" in this definition. You seem to be defining "Best Effort Security". Hey-ho. It's only a name, and just words. --- Introduction Since encryption alone mitigates only passive attacks, this risk is consistent with the expected level of protection. "Since encryption alone..." can be read two ways: 1. Only encryption can do this 2. Using only encryption with nothing else can only go so far I suggest you make some clarification to remove this ambiguity. "this risk is consistent with the expected..." I don't think so. I think the risk defines the level of protection that can be delivered. Expectations need to be set and this document can do so by describing the risks and the likelihoods. --- For authentication based on peer capabilities to protect against MiTM attacks, capability advertisements need to be over an out-of-band authenticated channel that is itself resistant to MiTM attack. I had a lot of trouble parsing the first clause in this sentence. Is it the peer capabilities that can protect against MiTM attacks? Or is it the authentication that does the protection? I think you are saying... In order that authentication mechanisms can protect against active MiTM attacks on capability exchanges between peers, those capability exchanges need to be performed over... But why are you insistent on an out-of-band channel? Surely any authenticated channel that is resistant to MiTM attacks will be good enough? --- OS protocols will attempt to establish encrypted communication whenever both parties are capable of such, and authenticated communication if that is also possible. This last outcome will occur if not all parties to a communication support encryption (or if an active attack makes it appear that this is the case). Is there any element of choice here? The text says not. --- For a particular protocol or application, if and when all but a negligible fraction of peers support encryption, the baseline security may be raised from cleartext to always require encryption. Similarly, once support for authentication is near-universal, the baseline may be raised to always require authentication. I don't know what this means! I think it says that at some moment in time the Internet Police will ban the use of unencrypted use of a protocol or application. Or maybe it says that new implementations can require encryption and refuse to operate with legacy implementations. Or perhaps you mean that the default behaviour should be to try for encryption. Or perhaps you are just talking about what the user can expect. --- The abbreviation "CA" is used without expansion. --- Section 1.1 DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the Internet- wide, any-to-any authentication requirement noted above. Did I miss the any-to-any requirement? I looked back but didn't find it. --- Section 1.1 makes a good case about encryption without authentication being of value. But this seems to be making a different (although equally valid) case from the basis of the document that is about OS. This comes back to the "opportunistic" versus "best effort" thing. --- Section 1.1 The use of encryption defends against pervasive monitoring and other passive attacks (which are employed not only by nation states). The parenthesised text can probably be dropped. It is not a discussion you need to have here. --- Section 1.1 For some applications or protocols the set of potential peers includes a long tail of implementations that support only cleartext. On third reading I got what the "long tail" refers to. How about... For some applications or protocols it is anticipated that the set of potential peers that only support cleartext will persist for a long time. --- Section 1.2 This document proposes a change of perspective. Why is it a proposal in what you plan to publish as an IETF Consensus RFC? I assume you don't really want this to be Experimental. --- I am fine with the concept of opportunistic security and like it. But I think I reject the hypothesis in Section 1.2 that the old world is "expect full security and notify when not achieved" and that the new world is "expect no security and get the best you can." I think the new world is / should be "configure the level of security that is acceptable to you, get at least that security and maybe better, or get notified if it is not as good." This is more subtle than your proposal but involves the user in a way that I think is important. That is, if a user desires security, it is not enough to say "the protocol is designed to get as much security as it can" - the user actually wants to know if the security level is low, and may want no traffic if the security level is too low. This does not reject the idea of OS, but merely the choice presented in Section 1.2. In fact, Section 3 makes these trade-offs pretty clear, so I think that all that is needed is to moderate the language in this section. (Although Section 5 seems to favour some sort of autonomy within the protocol or protocol implementation such that various fallbacks might "just happen".) --- Section 3 OS provides a near-term approach to counter passive attacks by removing barriers to the widespread use of encryption. This is probably true, and definitely a motivation, and not a Design Principle. Not appropriate in this section of the document. --- Section 3 I had to read "Emphasize enabling communication" and the following text a couple of time to extract the right meaning. What you have has two different meanings, and you mean "enablement of" (otherwise "an enabling communication" is inferred). --- Section 5 has... The choice to implement or enable fallback should only be made in response to significant operational obstacles. ...but no mention of who makes the choice for enablement. I think you need that such fallback is never a default action and always requires operator/user intervention since forcing such a fallback sounds like an effective attack. --- One point that I would possibly have entered as a Discuss were I not Abstaining is that I am surprised that there is no discussion of mechanisms that can be used to detect MiTM attacks on unauthenticated encryption key exchanges. Detection is a useful tool since, while it can't help with protection of data, it can at least warn the user to stop relying on the security of the data channel. From nobody Mon Sep 15 22:17:25 2014 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 7B4671A02BB; Mon, 15 Sep 2014 22:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 g2ZoJFCA5Kdw; Mon, 15 Sep 2014 22:17:23 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC43D1A02BA; Mon, 15 Sep 2014 22:17:22 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6DB43509B6; Tue, 16 Sep 2014 01:17:21 -0400 (EDT) Message-ID: <5417C7E6.2010104@seantek.com> Date: Mon, 15 Sep 2014 22:17:26 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: smime@ietf.org, pkix@ietf.org, saag@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020704060401080901020906" Archived-At: http://mailarchive.ietf.org/arch/msg/saag/gsyvkL0nqA_nTtXz1D4d_RMoxZg Subject: [saag] New Version Notification for draft-josefsson-pkix-textual-06.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: Tue, 16 Sep 2014 05:17:24 -0000 This is a cryptographically signed message in MIME format. --------------ms020704060401080901020906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Greetings S/MIME, PKIX, and SAAG lists: A revised draft of the PKIX/PKCS/CMS text encodings has been published.=20 There are "medium changes", including the addition of the PUBLIC KEY=20 label (corresponding to SubjectPublicKeyInfo). It's worth a look. It is pretty close to done, but look forward to reactions and comments. Kind regards, Sean Leonard -------- Forwarded Message -------- Subject: New Version Notification for draft-josefsson-pkix-textual-06.tx= t Date: Mon, 15 Sep 2014 21:54:19 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-josefsson-pkix-textual-06.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-josefsson-pkix-textual Revision: 06 Title: Text Encodings of PKIX and CMS Structures Document date: 2014-09-15 Group: Individual Submission Pages: 18 URL: http://www.ietf.org/internet-drafts/draft-josefsson-pkix-textual-06.= txt Status: https://datatracker.ietf.org/doc/draft-josefsson-pkix-textual/ Htmlized: http://tools.ietf.org/html/draft-josefsson-pkix-textual-06 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-josefsson-pkix-textual-06 Abstract: This document describes and discusses the text encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS), The text encodings are well-known, are implemented by several applications and= libraries, and are widely deployed. This document is intended to articulate the de-facto rules that existing implementations operate by, and to give recommendations that will promote interoperability going forward. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------ms020704060401080901020906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKTDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIFKjCCBBKgAwIBAgIRAMqTPDG7qW6mzJC+EpK9B3wwDQYJKoZIhvcN AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMx MTMwMDAwMDAwWhcNMTQxMTMwMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRkZXYraWV0ZkBz ZWFudGVrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM+J9tKgDs1LQtaD c+c4E58tCUQRNZiWbM1drOhLq2oSj75LuxPrrZy4XGjWoQFq9qGYHgivboRKoo2guKi2R5xr f/pZ27ELY5jCa3BQs4Q2YwziXWM5rktnFL2amO2MMwhuo0n7OIMDYftvTEun2mOrnJ3G53zv awQdMbuRiHSNwc7DzWJwAjZQWFO8OF+BgNPzMDQGmzYQ4MVNk8NX5ecNVbfusUU1wZOlfdy8 lWTfcASDqa9jLoaAiSx2ay4q7/5m0BOWqOKZCS0f7MmIUtSqODEoiZkd7oCj5MRKOg2ZLia3 3JN+oS5rTKN8rs4u4ZF5g8zypHS5TY/l3pNRlrcCAwEAAaOCAeQwggHgMB8GA1UdIwQYMBaA FHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQaZuXe8vDwU+japyFW3zSvIW6TxjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQ ME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRp Y2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcw AoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25h bmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2Eu Y29tMB8GA1UdEQQYMBaBFGRlditpZXRmQHNlYW50ZWsuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQA9Hb2X7rWPm//NFnvGoQYaeMhMjE6RTKmRd47UHzMfWE2/5myX518DB+kTa5iQDbKYRuJp 3A+f9m4kxT3Ri8VjZDh2vCEXZp1uVqxoLhGj76YBgdJstQmIH4kfI4LWrY8XrPhlX3JmHjD6 hShafLgR37hrLrOsWaigU9jlX6LzI5oxDKUE0aYpvxSOg1KB4AB3jx9VF/gA3vqYpL+jNumI nz7kcbY4xIcASmp8BrTMtOvzJ6Zs64yZom7FsE/r3yca4zDx+qNBsE2d9ljRDEiAts5Oopke eFsdpSQzndDwO1geofml50cWXK9lfB5pAdrL+NC+iE75M7Ztz8SZ0FkFMYIEHDCCBBgCAQEw gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQDKkzwxu6lu psyQvhKSvQd8MAkGBSsOAwIaBQCgggJHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE0MDkxNjA1MTcyNlowIwYJKoZIhvcNAQkEMRYEFKeMZgR4aCQmPWkN 9gpQv72lJYnHMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNV BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09N T0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIRAMqTPDG7qW6mzJC+EpK9B3wwgbwGCyqGSIb3DQEJEAIL MYGsoIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAypM8 MbupbqbMkL4Skr0HfDANBgkqhkiG9w0BAQEFAASCAQBLmAxYXbTbFdfaDrqsfziIw9ujF/CW IwMVYgD6kCDXi8+EHaXgntHUWQGdAv1cHYxzMr4sTqEK/Y1Uo9u3hyL3CWxZFgFwIFjRcVvG CmCC3f6PjGOBsg9PModen02Am5ZplxbzNBEWhp/+CZBtlKT7mFEXrJCVT0t1NlVjGRTZXbR8 nPezXYRXJkIuTq+NN+Rlu0pCDmJ3J1GPHutbIOlZ2BZlxn0fHCURh6G1AaT0m2ziX38DMpUK ZBO28aShulxDquP9uhjIskXWeu6hRFOPtzs/w4DAnj8teLZJtTwawUcjbYPCBHX0QrXdBNQC f79C/Rn7Gfx2jW5csTzBEup/AAAAAAAA --------------ms020704060401080901020906-- From nobody Tue Sep 16 02:37:10 2014 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 F2C0D1A048A; Tue, 16 Sep 2014 02:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 tzlZnM52pzM7; Tue, 16 Sep 2014 02:37:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 334AA1A02DC; Tue, 16 Sep 2014 02:37:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 02:37:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4xzsdT4I8DGbMQI3FqWfxAKyrYA Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:37:07 -0000 Martin Stiemerling has entered the following ballot position for draft-dukhovni-opportunistic-security-04: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am not done with my review, but in the meanwhile I have question: How does this draft related to the old Better-Than-Nothing Security (btns) working group [1] and their output? [1] http://www.ietf.org/wg/concluded/btns.html From nobody Tue Sep 16 03:14:51 2014 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 6816A1A027C; Tue, 16 Sep 2014 03:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 9Xk73FpnzW4e; Tue, 16 Sep 2014 03:14:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD41A048D; Tue, 16 Sep 2014 03:14:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DE189BE0A; Tue, 16 Sep 2014 11:14:40 +0100 (IST) 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 U_1BqqPH27ZW; Tue, 16 Sep 2014 11:14:38 +0100 (IST) Received: from [10.87.48.5] (unknown [86.42.31.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4ADE2BDFF; Tue, 16 Sep 2014 11:14:38 +0100 (IST) Message-ID: <54180D8E.6070706@cs.tcd.ie> Date: Tue, 16 Sep 2014 11:14:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Martin Stiemerling , The IESG References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> In-Reply-To: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-bW9UFYRjvE-X3BX4fqQI8vawq0 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 16 Sep 2014 10:14:48 -0000 Hi Martin, On 16/09/14 10:37, Martin Stiemerling wrote: > Martin Stiemerling has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: No Record > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am not done with my review, but in the meanwhile I have question: > > How does this draft related to the old Better-Than-Nothing Security > (btns) working group [1] and their output? I think its fair to say this LC discussion involved some of the same protagonists and some of the same arguments. Hopefully this RFC would short-circuit a part of the debate that happened back then (*) but more recently in the httpbis WG. There was also a bit of that debate in chartering tcpinc. The debate that this ought short-circuit is the part about the overall legitimacy of the approach. So this draft should save time, energy and good-will when an OS approach is proposed for other protocols - that part of the discussion seems to me at least to be contentious, so that can be a non-trivial saving. Functionally, I think one could describe the output from BTNS as following the OS design pattern, but not that successfully. (The lack of success conclusion being based on the lack of deployment, it'd probably not be productive to try analyse the reasons for that further right now - see below.) Some of those involved in BTNS have been working on another go at applying the OS approach to IPsec. That work has not yet been chartered anywhere but we have had a couple of updates at saag sessions [2] ([2] btw doesn't use the OS term - it was done while we were still flailing about with imperfect term selection;-) If that work got sufficient traction to be chartered, then this draft should help with that, again by legitimising the design pattern. The discussion as to why BTNS wasn't successful, and why some proposed new work might succeed, would of course still need to be had at chartering time. Hope that covers it, Cheers, S. [2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf (*) I wasn't involved in BTNS really, other than to watch the fireworks from the sidelines. From that perspective, I think that history probably explains some of the difficulty getting agreement with this draft. > > [1] http://www.ietf.org/wg/concluded/btns.html > > From nobody Tue Sep 16 03:43:43 2014 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 9CEF61A059F; Tue, 16 Sep 2014 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 S-d8sA90PDIo; Tue, 16 Sep 2014 03:43:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9261A0574; Tue, 16 Sep 2014 03:43:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7256DBE80; Tue, 16 Sep 2014 11:43:37 +0100 (IST) 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 oKzgCWTxVVjM; Tue, 16 Sep 2014 11:43:34 +0100 (IST) Received: from [10.87.48.5] (unknown [86.42.31.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6B93EBE35; Tue, 16 Sep 2014 11:43:34 +0100 (IST) Message-ID: <54181456.202@cs.tcd.ie> Date: Tue, 16 Sep 2014 11:43:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Adrian Farrel , The IESG References: <20140915171334.989.63043.idtracker@ietfa.amsl.com> In-Reply-To: <20140915171334.989.63043.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0aes4xR5lF7P5il-u3BaTuYD-mI Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Adrian Farrel's Abstain on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 16 Sep 2014 10:43:41 -0000 Hiya, Thanks for the detailed review. On 15/09/14 18:13, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: Abstain > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > It is good and helpful, in my opinion, for the IETF to give an > explanation of Opportunistic Security and advocate its use. > > The data tracker currently shows "Consensus: Unknown" and I think that > is actually a fair representation of the state of affairs. It is, > however, not a state in which we can publish an IETF Stream RFC. We should just get rid of that checkbox, which as you know is only about boilerplate text selection and is misleading in many ways, including the new one you've now just invented:-) > Having read a lot of the email thread resulting from IETF last call > and looked at the changes in the last few revisions I conclude that > there is general support for the technical content of this document, > but that there are a good number of unaddressed issues with the > development and presentation of that content. Actually I do not agree that those were not addressed and I claim that is apparent if one reads all the many LC mails and the various versions of the draft. I think it is entirely fair to say that the consensus for the specific text is rough, with some people in the rough who were significantly invested in the LC. That does not mean that concerns were not addressed. If there are specific points raised that were never addressed then I would be very interested in those. That is however, not the same as a point having been repeatedly re-raised after having been addressed some time previously. Mails that re-raise such issues do not IMO deserve a blow-by-blow response every time they are sent. And nor do all editorial suggestions especially when the editor is faced with multiple overlapping and sometimes conflicting suggestions from different folks. > It may be true that > addressing those points would not make a substantive difference to the > technical ideas in the document, but that does not mean that the > document would not be improved by attentive work. My take of the diffs between -02, -03 and -04 is that we have in fact being going sideways. I see no reason to assume that would change by extending the IETF LC. (IESG evaluation comments might help there though I hope, since you all have been less involved in the LC. And yes, that's not supposed to be how we fix stuff like this, but perhaps in this case its the best we can do. Apologies for abusing your time like that to the extent I am;-) > At the moment I am sufficiently unclear on the consensus for the > publication of this document to be either able to place a Discuss on > the absence of consensus or to be able to ballot No Objection. Hence > this Abstain. That's a comprehensible position I guess. Seems like a bit of an innovation in the semantics of abstain ballots, but innovating like that is fine by me. > I wish more work had been / would be done to build consensus or that > the document was advanced either as "published without consensus" or > on the Independent Stream. I also wish we had a less rough consensus, and am partly to blame there, sharing that blame with all of those heavily involved in the LC). I do not agree at all that "roughness of consensus on the text" as we have here implies taking the ISE route is a good plan. In this case the ISE route would not be a good plan. Once we have the full set of ballots I'll work with the author and shepherd to handle your comments below. Some of 'em are very good (I don't think MITM detection was raised during the LC, though it is research-level tricky in the general case), other ones seems just fine (modulo the "going sideways" point) and yet others might need a bit of back and forth better done when we've a full set of comments. Thanks, S. > > ========== > > I have spent too long hanging around with sales staff and this has made > me over-sensitive to the use of language that smells of marketing. I > apologise for any over-reaction on my part, but I presume that the > purpose of publishing the document is to deliver a useful and clear > statement, so I think that polishing might not be a waste of time. > If I was entering this Comment as part of IETF last call I would expect > a reasonable discussion of the cost/benefit of not changing the text to > address my thoughts. But, obviously, I am not. Furthermore, I am not > raising these points as Discusses so you can work through them with your > shepherding AD and ignore me if you think that I am wrong or that the > effort is not worth the results. > > - - - - > > Abstract... > > Protocol designs based on > Opportunistic Security remove barriers to the widespread use of > encryption on the Internet by using encryption even when > authentication is not available > > So, this says "remove barriers to X by using X". > I think there is probably something additional you need to say before > this sentence. For example, "Most approaches to the use of encryption > on the Internet depend on the use authentication to foo. This makes > encryption unattractive because bar." > > --- > > Introduction > > Broadly speaking, Opportunistic Security (OS) is a pragmatic risk > management approach. > > "pragmatic" is redundant in the description of "risk management". > > "...approach" to what? > > --- > > Introduction > > With Opportunistic Security, one applies the > tools at hand > > This implies to me that no changes or modifications to protocols are > needed to achieve OS. I don't believe that is true. > > --- > > The definition presented in Section 1 is OK as far as it goes, but > isn't it missing also the existence of the capability in the protocol > itself? > > Isn't a fundamental part of OS that the operation of encryption can be > without manual keying and therefore without the configuration of > security adjacencies? I think that what is missing from this document, > and possibly from this definition, is a description of why security > (specifically encryption) is not widely used in the Internet today. > > It is also a little questionable to me what is "opportunistic" in this > definition. You seem to be defining "Best Effort Security". Hey-ho. It's > only a name, and just words. > > --- > > Introduction > > Since encryption alone mitigates only > passive attacks, this risk is consistent with the expected level of > protection. > > "Since encryption alone..." can be read two ways: > 1. Only encryption can do this > 2. Using only encryption with nothing else can only go so far > I suggest you make some clarification to remove this ambiguity. > > "this risk is consistent with the expected..." I don't think so. I think > the risk defines the level of protection that can be delivered. > Expectations need to be set and this document can do so by describing > the risks and the likelihoods. > > --- > > For authentication based on peer capabilities to protect > against MiTM attacks, capability advertisements need to be over an > out-of-band authenticated channel that is itself resistant to MiTM > attack. > > I had a lot of trouble parsing the first clause in this sentence. Is it > the peer capabilities that can protect against MiTM attacks? Or is it > the authentication that does the protection? I think you are saying... > In order that authentication mechanisms can protect against active > MiTM attacks on capability exchanges between peers, those capability > exchanges need to be performed over... > > But why are you insistent on an out-of-band channel? Surely any > authenticated channel that is resistant to MiTM attacks will be good > enough? > > --- > > OS protocols will attempt to establish encrypted communication > whenever both parties are capable of such, and authenticated > communication if that is also possible. This last outcome will > occur if not all parties to a communication support encryption (or if > an active attack makes it appear that this is the case). > > Is there any element of choice here? The text says not. > > --- > > For a particular protocol or application, if and when all but a > negligible fraction of peers support encryption, the baseline > security may be raised from cleartext to always require encryption. > Similarly, once support for authentication is near-universal, the > baseline may be raised to always require authentication. > > I don't know what this means! > I think it says that at some moment in time the Internet Police will > ban the use of unencrypted use of a protocol or application. Or maybe > it says that new implementations can require encryption and refuse to > operate with legacy implementations. Or perhaps you mean that the > default behaviour should be to try for encryption. Or perhaps you are > just talking about what the user can expect. > > --- > > The abbreviation "CA" is used without expansion. > > --- > > Section 1.1 > > DNSSEC is not > sufficiently widely deployed to allow DANE to satisfy the Internet- > wide, any-to-any authentication requirement noted above. > > Did I miss the any-to-any requirement? I looked back but didn't find it. > > --- > > Section 1.1 makes a good case about encryption without authentication > being of value. But this seems to be making a different (although > equally valid) case from the basis of the document that is about OS. > This comes back to the "opportunistic" versus "best effort" thing. > > --- > > Section 1.1 > > The use of encryption defends against pervasive monitoring > and other passive attacks (which are employed not only by nation > states). > > The parenthesised text can probably be dropped. It is not a discussion > you need to have here. > > --- > > Section 1.1 > > For some applications or protocols the set of potential peers > includes a long tail of implementations that support only cleartext. > > On third reading I got what the "long tail" refers to. How about... > > For some applications or protocols it is anticipated that the set of > potential peers that only support cleartext will persist for a long > time. > > --- > > Section 1.2 > > This document proposes a change of perspective. > > Why is it a proposal in what you plan to publish as an IETF Consensus > RFC? I assume you don't really want this to be Experimental. > > --- > > I am fine with the concept of opportunistic security and like it. But > I think I reject the hypothesis in Section 1.2 that the old world is > "expect full security and notify when not achieved" and that the new > world is "expect no security and get the best you can." I think the new > world is / should be "configure the level of security that is acceptable > to you, get at least that security and maybe better, or get notified if > it is not as good." This is more subtle than your proposal but involves > the user in a way that I think is important. That is, if a user desires > security, it is not enough to say "the protocol is designed to get as > much security as it can" - the user actually wants to know if the > security level is low, and may want no traffic if the security level is > too low. > > This does not reject the idea of OS, but merely the choice presented in > Section 1.2. > > In fact, Section 3 makes these trade-offs pretty clear, so I think > that all that is needed is to moderate the language in this section. > (Although Section 5 seems to favour some sort of autonomy within the > protocol or protocol implementation such that various fallbacks might > "just happen".) > > --- > > Section 3 > > OS provides a near-term approach to counter passive attacks by > removing barriers to the widespread use of encryption. > > This is probably true, and definitely a motivation, and not a Design > Principle. Not appropriate in this section of the document. > > --- > > Section 3 > > I had to read "Emphasize enabling communication" and the following text > a couple of time to extract the right meaning. What you have has two > different meanings, and you mean "enablement of" (otherwise "an > enabling communication" is inferred). > > --- > > Section 5 has... > > The choice > to implement or enable fallback should only be made in response to > significant operational obstacles. > > ...but no mention of who makes the choice for enablement. I think you > need that such fallback is never a default action and always requires > operator/user intervention since forcing such a fallback sounds like an > effective attack. > > --- > > One point that I would possibly have entered as a Discuss were I not > Abstaining is that I am surprised that there is no discussion of > mechanisms that can be used to detect MiTM attacks on unauthenticated > encryption key exchanges. Detection is a useful tool since, while it > can't help with protection of data, it can at least warn the user to > stop relying on the security of the data channel. > > From nobody Tue Sep 16 06:00:15 2014 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 8CA5F1A06DE; Tue, 16 Sep 2014 05:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 otL2zrhGbqND; Tue, 16 Sep 2014 05:59:55 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8217A1A03D1; Tue, 16 Sep 2014 05:59:54 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w7so6483930lbi.32 for ; Tue, 16 Sep 2014 05:59:52 -0700 (PDT) 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=dSnUuqxKpQmq25wOku3w3aDKW6MPZIGN3hzGQnzHQW0=; b=L/rLQWBtehpqe4iAqcgmYN84VchYZjGetZDOA1cyXNNKDQwGDFttide0jlBXEzPzD2 RIbEE09bFVZy5jGf2/Gw9UeeNYEa/C6tuEG/wtzeLwEas0TpTj1XHGO/is1mbIBj5k0Y X+Vks2+bxlpL9GuxYKnraoZuCXtyDQaldo69DA3sLxrJYJurphUbgZa9kwe0eSs8w8rr k4gOW9CoeW6AWu1cCWA/ui7gRLAor88hlgfnGu78081EclJYI2SX5b0EAP2fkC0e79a2 p5uYBaAH6j1JaMHvICm3ppfYggW3Ah/5Ko36TkOls5OREutopcb/1daPbN3rcdJjEgsd Q7mA== MIME-Version: 1.0 X-Received: by 10.152.19.66 with SMTP id c2mr37229346lae.64.1410872392807; Tue, 16 Sep 2014 05:59:52 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Tue, 16 Sep 2014 05:59:52 -0700 (PDT) In-Reply-To: References: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 08:59:52 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01493e46cbf99905032e53e7 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5-zNw_FDCPNrcFvx7S8DyWgkA5I Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, "saag@ietf.org" Subject: Re: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 16 Sep 2014 12:59:59 -0000 --089e01493e46cbf99905032e53e7 Content-Type: text/plain; charset=UTF-8 Hello, I appreciate the review and acceptance of my comments, thank you. Since posting my review on the OS draft, I have received feedback directly from several community members who either provided text and did not get a response (text was silently dropped) or raised a question and did not get a response (may have been seen as "in the rough", don't know). From the folks that provided unsolicited feedback to me, I would like to see if we can get some of the unanswered questioned addressed to understand the outcome in the draft. After additional review on specific text suggestions, I think the problem may have been a direct result of using GitHub for editing the draft. While this is a good and helpful tool, it seems it may have led to a gap in transparency as to why suggested text was accepted or dropped. If I am missing where to look for the answers as to why text was accepted/rejected, please provide a pointer. **Otherwise, if we plan to continue using such tools (and I think the answer is yes), we'll have to find a way to make this process more clear.** I have a few questions broken out below from the recent feedback. I tried to number each question to make this a bit easier to respond. 1. Text on "who is the intended audience for this draft" Eliot Lear had concerns that a particular question Dave Crocker had raised did not get a response. The request was to have the draft state for which audience the draft was intended. There was at one point text in a Github version of the draft that addressed this question, can you let me know why it was dropped? From what I can tell, it was dropped silently, so I'd just like to understand why, it may be fine, but wanted to check as folks may not have been aware that this text was even proposed to answer this question. I think this text was from Paul Wouters provided in GitHub. Were other opposed to including this information? Does it need to be tweaked? - This document is aimed primarily at protocol designers. It - promotes designs in which cryptographic protection against - both passive and active attacks works without creating barriers - to communication and can be rolled out incrementally as suitably - capable systems are deployed. This document is also aimed at - operators who set policy for systems that can make use of - opportunistic security. 2. Paul Wouters provided some feedback through the GitHub version between 3 and 4. I went through Paul's suggested text and think the difference in text could be answered with the question of who is the intended audience. Paul's text in some cases simplified the existing text and in other cases, he provided specific examples. I think his summary was adapted and replaced the abstract (may be wrong on that), so it seems some was accepted. >From my observation, many of the suggestions included examples that were not incorporated into version -04. Was there consensus to reduce the number of examples? Knowing the answer to this question, would explain why many of his suggestions were not accepted without the need for a point-by-point response to each proposal of that type. 3. If I am missing where to look for information on the accept/reject of edits through the GitHub process, a pointer would be greatly appreciated. Here are some specific points from reviewing Paul Woulter's submission that I'm not sure had a response, I can't generalize with the above catch-all, or I see similar enough text capturing the same point in the draft. I appreciate feedback from Paul Hoffman as shepherd or Viktor as editor for each of these points: a. Section 2. Terminology The last clause of the sentence was suggested and not accepted in the TOFU definition: In a protocol, TOFU - typically consists of accepting an asserted identity, without - authenticating that assertion, and caching a key or credential - associated with the identity. b. Section 3. Specific suggestions were provided on this section, but it has been completely re-worked, so the suggestions were not accepted. This is enough of a change that another review may have been warranted. I do like the version in draft-04 and think it was a positive improvement. Can you point me to agreement on the new text in this section as well as the discussion on accepting rejecting text that was proposed? I think this all boils down to better processes when tools like GitHub are used for editing. c. For the text in section 3 on "Maximize security peer by peer", version 3 had conditions for failure included and Paul suggested that operational consideration should also be listed. It looks like version 4 dropped any mention of it failing, can you point to the decision on this particular point as it would explain why Paul's suggested text was not accepted. Paul's starts with the "-" Opportunistic security strives to maximize security based on the capabilities of the peers. Communications traffic should generally be at least encrypted. Opportunistic security protocols may refuse to communicate with peers for which higher security is expected, - but for some reason is not achieved. The conditions under - which connections fail should generally be limited to operational - errors at one or the other peer or an active attack, so that - well-maintained systems rarely encounter problems in normal - use of opportunistic security. + but for some reason is not achieved. Advertised capability must match + reality to ensure the only condition under which there is a failure + of communication is when one or both peers are under an active attack. + d. Paul had also suggested text that looks like I addressed in one of my comments where he suggested a "set of CAs". I think we are good on that one now. e. Steve Kent's detailed review I have not gone through this point-by-point yet, but Steve also complained that he didn't get feedback. It's my observation that Steve tends to give very detailed reviews, so this one was no different from other ones (look at the SecDir review for one of the JOSE drafts). I do think understanding the accept/reject process when GitHub was used would be helpful. Can sets of suggestions be grouped to provide an explanation of why they were dropped? If not, a point-by point might be helpful. f. Did I miss anyone that gave a detailed review and didn't get this type of feedback? Some was not on list unfortunately. I may add to this list if I find some more specific points that I am not sure were addressed. Thanks! On Mon, Sep 15, 2014 at 10:59 AM, Paul Hoffman wrote: > > > Thanks for the comments. Those all seem reasonable and within the scope of > the rough consensus during IETF Last Call. Viktor will collect these and > other IESG comments for a new draft to be posted after the IESG telechat. > > --Paul Hoffman -- Best regards, Kathleen --089e01493e46cbf99905032e53e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I appreciate the revi= ew and acceptance of my comments, thank you.

Since= posting my review on the OS draft, I have received feedback directly from = several community members who either provided text and did not get a respon= se (text was silently dropped) or raised a question and did not get a respo= nse (may have been seen as "in the rough", don't know). =C2= =A0From the folks that provided unsolicited feedback to me, I would like to= see if we can get some of the unanswered questioned addressed to understan= d the outcome in the draft.

After additional revie= w on specific text suggestions, I think the problem may have been a direct = result of using GitHub for editing the draft. =C2=A0While this is a good an= d helpful tool, it seems it may have led to a gap in transparency as to why= suggested text was accepted or dropped. =C2=A0If I am missing where to loo= k for the answers as to why text was accepted/rejected, please provide a po= inter. =C2=A0**Otherwise, if we plan to continue using such tools (and I th= ink the answer is yes), we'll have to find a way to make this process m= ore clear.**

I have a few questions broken out bel= ow from the recent feedback. I tried to number each question to make this a= bit easier to respond.

1. Text on "who is th= e intended audience for this draft"
Eliot Lear had concerns = that a particular question Dave Crocker had raised did not get a response. = =C2=A0The request was to have the draft state for which audience the draft = was intended. =C2=A0There was at one point text in a Github version of the = draft that addressed this question, can you let me know why it was dropped?= =C2=A0From what I can tell, it was dropped silently, so I'd just like = to understand why, it may be fine, but wanted to check as folks may not hav= e been aware that this text was even proposed to answer this question. =C2= =A0I think this text was from Paul Wouters provided in GitHub. =C2=A0Were o= ther opposed to including this information? =C2=A0Does it need to be tweake= d?

- =C2=A0 =C2=A0 This document is aimed primaril= y at protocol designers. =C2=A0It
- =C2=A0 =C2=A0 promotes design= s in which cryptographic protection against
- =C2=A0 =C2=A0 both = passive and active attacks works without creating barriers
- =C2= =A0 =C2=A0 to communication and can be rolled out incrementally as suitably=
- =C2=A0 =C2=A0 capable systems are deployed. =C2=A0This documen= t is also aimed at
- =C2=A0 =C2=A0 operators who set policy for s= ystems that can make use of
- =C2=A0 =C2=A0 opportunistic securit= y.

2. Paul Wouters provided some feedback through = the GitHub version between 3 and 4. =C2=A0I went through Paul's suggest= ed text and think the difference in text could be answered with the questio= n of who is the intended audience. =C2=A0Paul's text in some cases simp= lified the existing text and in other cases, he provided specific examples.= =C2=A0I think his summary was adapted and replaced the abstract (may be wr= ong on that), so it seems some was accepted.

From = my observation, many of the suggestions included examples that were not inc= orporated into version -04. =C2=A0Was there consensus to reduce the number = of examples? =C2=A0Knowing the answer to this question, would explain why m= any of his suggestions were not accepted without the need for a point-by-po= int response to each proposal of that type.=C2=A0

=
3. If I am missing where to look for information on the acce= pt/reject of edits through the GitHub process, a pointer would be greatly a= ppreciated. =C2=A0Here are some specific points from reviewing Paul Woulter= 's submission that I'm not sure had a response, I can't general= ize with the above catch-all, or I see similar enough text capturing the sa= me point in the draft. =C2=A0I appreciate feedback from Paul Hoffman as she= pherd or Viktor as editor for each of these points:

a. Section 2. Terminology
The last clause of the sentence was s= uggested and not accepted in the TOFU definition:
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 <t hangText=3D"Trust on First Use (TOFU):">In= a protocol, TOFU
- =C2=A0 =C2=A0 =C2=A0 typically consists of ac= cepting an asserted identity, without
- =C2=A0 =C2=A0 =C2=A0 auth= enticating that assertion, and caching a key or credential
- =C2= =A0 =C2=A0 =C2=A0 associated with the identity. =C2=A0

=

b. Section 3.=C2=A0
Specific suggestions were= provided on this section, but it has been completely re-worked, so the sug= gestions were not accepted. =C2=A0This is enough of a change that another r= eview may have been warranted. =C2=A0I do like the version in draft-04 and = think it was a positive improvement. =C2=A0Can you point me to agreement on= the new text in this section as well as the discussion on accepting reject= ing text that was proposed? =C2=A0I think this all boils down to better pro= cesses when tools like GitHub are used for editing.

c. For the text in section 3 on "Maximize security peer by peer"= ;, version 3 had conditions for failure included and Paul suggested that op= erational consideration should also be listed. =C2=A0It looks like version = 4 dropped any mention of it failing, can you point to the decision on this = particular point as it would explain why Paul's suggested text was not = accepted. =C2=A0Paul's starts with the "-"

=C2=A0 =C2=A0 =C2=A0<t hangText=3D"Maximize security peer by= peer:"> Opportunistic
=C2=A0 =C2=A0 =C2=A0 security stri= ves to maximize security based on the capabilities
=C2=A0 =C2=A0 = =C2=A0 of the peers. =C2=A0Communications traffic should generally be at
=C2=A0 =C2=A0 =C2=A0 least encrypted. =C2=A0Opportunistic security = protocols may refuse to
=C2=A0 =C2=A0 =C2=A0 communicate with pee= rs for which higher security is expected,
- =C2=A0 =C2=A0 but for= some reason is not achieved. =C2=A0The conditions under
- =C2=A0= =C2=A0 which connections fail should generally be limited to operational
- =C2=A0 =C2=A0 errors at one or the other peer or an active attac= k, so that
- =C2=A0 =C2=A0 well-maintained systems rarely encount= er problems in normal
- =C2=A0 =C2=A0 use of opportunistic securi= ty. =C2=A0</t>
+ =C2=A0 =C2=A0 but for some reason is not a= chieved. Advertised capability must match
+ =C2=A0 =C2=A0 reality= to ensure the only condition under which there is a failure
+ = =C2=A0 =C2=A0 of communication is when one or both peers are under an activ= e attack.
+ =C2=A0 =C2=A0 </t>

d. Paul had also suggested text that looks like I addressed in = one of my comments where he suggested a "set of CAs". =C2=A0I thi= nk we are good on that one now.

e. Steve Kent'= s detailed review
I have not gone through this point-by-point yet= , but Steve also complained that he didn't get feedback. =C2=A0It's= my observation that Steve tends to give very detailed reviews, so this one= was no different from other ones (look at the SecDir review for one of the= JOSE drafts). =C2=A0I do think understanding the accept/reject process whe= n GitHub was used would be helpful. =C2=A0Can sets of suggestions be groupe= d to provide an explanation of why they were dropped? =C2=A0If not, a point= -by point might be helpful.

f. =C2=A0Did I miss an= yone that gave a detailed review and didn't get this type of feedback? = =C2=A0Some was not on list unfortunately. =C2=A0I may add to this list if I= find some more specific points that I am not sure were addressed.

Thanks!


On Mon, Sep 15, 2014 at 10:59 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
<shepherd hat on>

Thanks for the comments. Those all seem reasonable and within the scope of = the rough consensus during IETF Last Call. Viktor will collect these and ot= her IESG comments for a new draft to be posted after the IESG telechat.

--Paul Hoffman


<= br>
--

Best regards,
Kathleen<= /div>
--089e01493e46cbf99905032e53e7-- From nobody Tue Sep 16 06:33:55 2014 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 B23C11A0707; Tue, 16 Sep 2014 06:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Gazn-J7OikQR; Tue, 16 Sep 2014 06:33:48 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C081A1A0703; Tue, 16 Sep 2014 06:33:47 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so6683392lbg.30 for ; Tue, 16 Sep 2014 06:33:45 -0700 (PDT) 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=11CwbaXL03oKGsFNW7QPoozS50gh4EHpxjP3EkUZ9A4=; b=zs64/pxxzsByz0dVqWSQtsspXdy6wR6IV0YYIDcYKC0hL2JwSbap4BwsR8fox5QLWZ ndx1nXHAKx22vAZwT6Li5hl28qhspUZkKIcb0z0ssHnKz5QqhLiUX0b9IxL3cxXiF3/f fJB38cRhC/mmJ8yMObN2oN4K/FPGpNG59JjwgRDTf9ANRPDb8Cy6MytZL4/JRH1Q0bSo LmJ8fQXG/58GPWTWZC9DE+8YgQXyzaHwi545yeeeI1HtLUinPWtbPnuWdDGU0JXpc6xT 7S6kubx20CpsLXeXQ63yhJmDif9+DesF4vD/Lz89ufDwICIKyMI38AjyzRHC9BvEfyJW H7BA== MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr34372467lbb.4.1410874425846; Tue, 16 Sep 2014 06:33:45 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Tue, 16 Sep 2014 06:33:45 -0700 (PDT) In-Reply-To: References: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 09:33:45 -0400 Message-ID: From: Kathleen Moriarty To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8f64732ff9af6805032ecc4c Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7_BJXPZNbv1hM7shHQqu__NhDMo Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, "saag@ietf.org" Subject: Re: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 16 Sep 2014 13:33:51 -0000 --e89a8f64732ff9af6805032ecc4c Content-Type: text/plain; charset=UTF-8 I should note that I believe the text provided was offlist in response to a request from Viktor to several of the active participants to review a version between -03 and -04. I think this is where a bunch of the comments were dropped without feedback as to why it was accepted/rejected. I *think* Steve Kent also posted his to the list, but others may not have done the same. On Tue, Sep 16, 2014 at 8:59 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > I appreciate the review and acceptance of my comments, thank you. > > Since posting my review on the OS draft, I have received feedback directly > from several community members who either provided text and did not get a > response (text was silently dropped) or raised a question and did not get a > response (may have been seen as "in the rough", don't know). From the > folks that provided unsolicited feedback to me, I would like to see if we > can get some of the unanswered questioned addressed to understand the > outcome in the draft. > > After additional review on specific text suggestions, I think the problem > may have been a direct result of using GitHub for editing the draft. While > this is a good and helpful tool, it seems it may have led to a gap in > transparency as to why suggested text was accepted or dropped. If I am > missing where to look for the answers as to why text was accepted/rejected, > please provide a pointer. **Otherwise, if we plan to continue using such > tools (and I think the answer is yes), we'll have to find a way to make > this process more clear.** > > I have a few questions broken out below from the recent feedback. I tried > to number each question to make this a bit easier to respond. > > 1. Text on "who is the intended audience for this draft" > Eliot Lear had concerns that a particular question Dave Crocker had raised > did not get a response. The request was to have the draft state for which > audience the draft was intended. There was at one point text in a Github > version of the draft that addressed this question, can you let me know why > it was dropped? From what I can tell, it was dropped silently, so I'd just > like to understand why, it may be fine, but wanted to check as folks may > not have been aware that this text was even proposed to answer this > question. I think this text was from Paul Wouters provided in GitHub. > Were other opposed to including this information? Does it need to be > tweaked? > > - This document is aimed primarily at protocol designers. It > - promotes designs in which cryptographic protection against > - both passive and active attacks works without creating barriers > - to communication and can be rolled out incrementally as suitably > - capable systems are deployed. This document is also aimed at > - operators who set policy for systems that can make use of > - opportunistic security. > > 2. Paul Wouters provided some feedback through the GitHub version between > 3 and 4. I went through Paul's suggested text and think the difference in > text could be answered with the question of who is the intended audience. > Paul's text in some cases simplified the existing text and in other cases, > he provided specific examples. I think his summary was adapted and > replaced the abstract (may be wrong on that), so it seems some was accepted. > > From my observation, many of the suggestions included examples that were > not incorporated into version -04. Was there consensus to reduce the > number of examples? Knowing the answer to this question, would explain why > many of his suggestions were not accepted without the need for a > point-by-point response to each proposal of that type. > > > 3. If I am missing where to look for information on the accept/reject of > edits through the GitHub process, a pointer would be greatly appreciated. > Here are some specific points from reviewing Paul Woulter's submission > that I'm not sure had a response, I can't generalize with the above > catch-all, or I see similar enough text capturing the same point in the > draft. I appreciate feedback from Paul Hoffman as shepherd or Viktor as > editor for each of these points: > > a. Section 2. Terminology > The last clause of the sentence was suggested and not accepted in the TOFU > definition: > In a protocol, TOFU > - typically consists of accepting an asserted identity, without > - authenticating that assertion, and caching a key or credential > - associated with the identity. > > > b. Section 3. > Specific suggestions were provided on this section, but it has been > completely re-worked, so the suggestions were not accepted. This is enough > of a change that another review may have been warranted. I do like the > version in draft-04 and think it was a positive improvement. Can you point > me to agreement on the new text in this section as well as the discussion > on accepting rejecting text that was proposed? I think this all boils down > to better processes when tools like GitHub are used for editing. > > c. For the text in section 3 on "Maximize security peer by peer", version > 3 had conditions for failure included and Paul suggested that operational > consideration should also be listed. It looks like version 4 dropped any > mention of it failing, can you point to the decision on this particular > point as it would explain why Paul's suggested text was not accepted. > Paul's starts with the "-" > > Opportunistic > security strives to maximize security based on the capabilities > of the peers. Communications traffic should generally be at > least encrypted. Opportunistic security protocols may refuse to > communicate with peers for which higher security is expected, > - but for some reason is not achieved. The conditions under > - which connections fail should generally be limited to operational > - errors at one or the other peer or an active attack, so that > - well-maintained systems rarely encounter problems in normal > - use of opportunistic security. > + but for some reason is not achieved. Advertised capability must match > + reality to ensure the only condition under which there is a failure > + of communication is when one or both peers are under an active > attack. > + > > > d. Paul had also suggested text that looks like I addressed in one of my > comments where he suggested a "set of CAs". I think we are good on that > one now. > > e. Steve Kent's detailed review > I have not gone through this point-by-point yet, but Steve also complained > that he didn't get feedback. It's my observation that Steve tends to give > very detailed reviews, so this one was no different from other ones (look > at the SecDir review for one of the JOSE drafts). I do think understanding > the accept/reject process when GitHub was used would be helpful. Can sets > of suggestions be grouped to provide an explanation of why they were > dropped? If not, a point-by point might be helpful. > > f. Did I miss anyone that gave a detailed review and didn't get this type > of feedback? Some was not on list unfortunately. I may add to this list > if I find some more specific points that I am not sure were addressed. > > Thanks! > > > On Mon, Sep 15, 2014 at 10:59 AM, Paul Hoffman > wrote: > >> >> >> Thanks for the comments. Those all seem reasonable and within the scope >> of the rough consensus during IETF Last Call. Viktor will collect these and >> other IESG comments for a new draft to be posted after the IESG telechat. >> >> --Paul Hoffman > > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --e89a8f64732ff9af6805032ecc4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I should note that I believe the text provided was offlist= in response to a request from Viktor to several of the active participants= to review a version between -03 and -04. =C2=A0I think this is where a bun= ch of the comments were dropped without feedback as to why it was accepted/= rejected. =C2=A0I *think* Steve Kent also posted his to the list, but other= s may not have done the same.

On Tue, Sep 16, 2014 at 8:59 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hello,

=
I appreciate the review and acceptance of my comments, thank you.

Since posting my review on the OS draft, I have receiv= ed feedback directly from several community members who either provided tex= t and did not get a response (text was silently dropped) or raised a questi= on and did not get a response (may have been seen as "in the rough&quo= t;, don't know). =C2=A0From the folks that provided unsolicited feedbac= k to me, I would like to see if we can get some of the unanswered questione= d addressed to understand the outcome in the draft.

After additional review on specific text suggestions, I think the problem= may have been a direct result of using GitHub for editing the draft. =C2= =A0While this is a good and helpful tool, it seems it may have led to a gap= in transparency as to why suggested text was accepted or dropped. =C2=A0If= I am missing where to look for the answers as to why text was accepted/rej= ected, please provide a pointer. =C2=A0**Otherwise, if we plan to continue = using such tools (and I think the answer is yes), we'll have to find a = way to make this process more clear.**

I have a fe= w questions broken out below from the recent feedback. I tried to number ea= ch question to make this a bit easier to respond.

= 1. Text on "who is the intended audience for this draft"
Eliot Lear had concerns that a particular question Dave Crocker had raise= d did not get a response. =C2=A0The request was to have the draft state for= which audience the draft was intended. =C2=A0There was at one point text i= n a Github version of the draft that addressed this question, can you let m= e know why it was dropped? =C2=A0From what I can tell, it was dropped silen= tly, so I'd just like to understand why, it may be fine, but wanted to = check as folks may not have been aware that this text was even proposed to = answer this question. =C2=A0I think this text was from Paul Wouters provide= d in GitHub. =C2=A0Were other opposed to including this information? =C2=A0= Does it need to be tweaked?

- =C2=A0 =C2=A0 This d= ocument is aimed primarily at protocol designers. =C2=A0It
- =C2= =A0 =C2=A0 promotes designs in which cryptographic protection against
=
- =C2=A0 =C2=A0 both passive and active attacks works without creating= barriers
- =C2=A0 =C2=A0 to communication and can be rolled out = incrementally as suitably
- =C2=A0 =C2=A0 capable systems are dep= loyed. =C2=A0This document is also aimed at
- =C2=A0 =C2=A0 opera= tors who set policy for systems that can make use of
- =C2=A0 =C2= =A0 opportunistic security.

2. Paul Wouters provid= ed some feedback through the GitHub version between 3 and 4. =C2=A0I went t= hrough Paul's suggested text and think the difference in text could be = answered with the question of who is the intended audience. =C2=A0Paul'= s text in some cases simplified the existing text and in other cases, he pr= ovided specific examples. =C2=A0I think his summary was adapted and replace= d the abstract (may be wrong on that), so it seems some was accepted.
=

From my observation, many of the suggestions included e= xamples that were not incorporated into version -04. =C2=A0Was there consen= sus to reduce the number of examples? =C2=A0Knowing the answer to this ques= tion, would explain why many of his suggestions were not accepted without t= he need for a point-by-point response to each proposal of that type.=C2=A0<= /div>


3. If I am missing where to look fo= r information on the accept/reject of edits through the GitHub process, a p= ointer would be greatly appreciated. =C2=A0Here are some specific points fr= om reviewing Paul Woulter's submission that I'm not sure had a resp= onse, I can't generalize with the above catch-all, or I see similar eno= ugh text capturing the same point in the draft. =C2=A0I appreciate feedback= from Paul Hoffman as shepherd or Viktor as editor for each of these points= :

a. Section 2. Terminology
The last cla= use of the sentence was suggested and not accepted in the TOFU definition:<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <t hangText=3D"Trust on First= Use (TOFU):">In a protocol, TOFU
- =C2=A0 =C2=A0 =C2=A0 = typically consists of accepting an asserted identity, without
- = =C2=A0 =C2=A0 =C2=A0 authenticating that assertion, and caching a key or cr= edential
- =C2=A0 =C2=A0 =C2=A0 associated with the identity. =C2= =A0


b. Section 3.=C2=A0
S= pecific suggestions were provided on this section, but it has been complete= ly re-worked, so the suggestions were not accepted. =C2=A0This is enough of= a change that another review may have been warranted. =C2=A0I do like the = version in draft-04 and think it was a positive improvement. =C2=A0Can you = point me to agreement on the new text in this section as well as the discus= sion on accepting rejecting text that was proposed? =C2=A0I think this all = boils down to better processes when tools like GitHub are used for editing.=

c. For the text in section 3 on "Maximize se= curity peer by peer", version 3 had conditions for failure included an= d Paul suggested that operational consideration should also be listed. =C2= =A0It looks like version 4 dropped any mention of it failing, can you point= to the decision on this particular point as it would explain why Paul'= s suggested text was not accepted. =C2=A0Paul's starts with the "-= "

=C2=A0 =C2=A0 =C2=A0<t hangText=3D"= Maximize security peer by peer:"> Opportunistic
=C2=A0 = =C2=A0 =C2=A0 security strives to maximize security based on the capabiliti= es
=C2=A0 =C2=A0 =C2=A0 of the peers. =C2=A0Communications traffi= c should generally be at
=C2=A0 =C2=A0 =C2=A0 least encrypted. = =C2=A0Opportunistic security protocols may refuse to
=C2=A0 =C2= =A0 =C2=A0 communicate with peers for which higher security is expected,
- =C2=A0 =C2=A0 but for some reason is not achieved. =C2=A0The cond= itions under
- =C2=A0 =C2=A0 which connections fail should genera= lly be limited to operational
- =C2=A0 =C2=A0 errors at one or th= e other peer or an active attack, so that
- =C2=A0 =C2=A0 well-ma= intained systems rarely encounter problems in normal
- =C2=A0 =C2= =A0 use of opportunistic security. =C2=A0</t>
+ =C2=A0 =C2= =A0 but for some reason is not achieved. Advertised capability must match
+ =C2=A0 =C2=A0 reality to ensure the only condition under which t= here is a failure
+ =C2=A0 =C2=A0 of communication is when one or= both peers are under an active attack.
+ =C2=A0 =C2=A0 </t>= ;


d. Paul had also suggested text t= hat looks like I addressed in one of my comments where he suggested a "= ;set of CAs". =C2=A0I think we are good on that one now.
e. Steve Kent's detailed review
I have not gone t= hrough this point-by-point yet, but Steve also complained that he didn'= t get feedback. =C2=A0It's my observation that Steve tends to give very= detailed reviews, so this one was no different from other ones (look at th= e SecDir review for one of the JOSE drafts). =C2=A0I do think understanding= the accept/reject process when GitHub was used would be helpful. =C2=A0Can= sets of suggestions be grouped to provide an explanation of why they were = dropped? =C2=A0If not, a point-by point might be helpful.

f. =C2=A0Did I miss anyone that gave a detailed review and didn'= ;t get this type of feedback? =C2=A0Some was not on list unfortunately. =C2= =A0I may add to this list if I find some more specific points that I am not= sure were addressed.

Thanks!

=

On Mon, Sep 15, 2014 at 10:59 AM, Paul Hoffman <= paul.hoffman@vpn= c.org> wrote:
<shepherd hat on>

Thanks for the comments. Those all seem reasonable and within the scope of = the rough consensus during IETF Last Call. Viktor will collect these and ot= her IESG comments for a new draft to be posted after the IESG telechat.

--Paul Hoffman



--
=

Best regards,
Kathleen



--

Best regards,
Kathleen
--e89a8f64732ff9af6805032ecc4c-- From nobody Tue Sep 16 06:36:50 2014 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 85C521A070A; Tue, 16 Sep 2014 06:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 CjerX20ckgeG; Tue, 16 Sep 2014 06:36:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 91F901A0714; Tue, 16 Sep 2014 06:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8EA9BE01; Tue, 16 Sep 2014 14:36:44 +0100 (IST) 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 Vh6P5zf38dTa; Tue, 16 Sep 2014 14:36:42 +0100 (IST) Received: from [10.87.48.5] (unknown [86.42.31.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E233BBE35; Tue, 16 Sep 2014 14:36:41 +0100 (IST) Message-ID: <54183CE9.8010902@cs.tcd.ie> Date: Tue, 16 Sep 2014 14:36:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Kathleen Moriarty , Paul Hoffman References: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vjaQeqjc93UGU635bZqI2chM4CA Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, "saag@ietf.org" Subject: Re: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 16 Sep 2014 13:36:49 -0000 On 16/09/14 14:33, Kathleen Moriarty wrote: > I should note that I believe the text provided was offlist in response to a > request from Viktor to several of the active participants to review a > version between -03 and -04. I think this is where a bunch of the comments > were dropped without feedback as to why it was accepted/rejected. I > *think* Steve Kent also posted his to the list, but others may not have > done the same. Ah, that sounds right, was wondering a bit about some of that. Will get back with more detail when I (or Viktor/Paul) have had a chance to go back to the list and get the relevant URLs but I do think all of those onlist messages did get responses that were sufficient, if not blow-by-blow in all cases. (Which I maintain is not always required, esp. when there's so much traffic and/or multiple conflicting editorial suggestions being handled.) But more anon, tomorrow probably. Cheers, S. > > On Tue, Sep 16, 2014 at 8:59 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hello, >> >> I appreciate the review and acceptance of my comments, thank you. >> >> Since posting my review on the OS draft, I have received feedback directly >> from several community members who either provided text and did not get a >> response (text was silently dropped) or raised a question and did not get a >> response (may have been seen as "in the rough", don't know). From the >> folks that provided unsolicited feedback to me, I would like to see if we >> can get some of the unanswered questioned addressed to understand the >> outcome in the draft. >> >> After additional review on specific text suggestions, I think the problem >> may have been a direct result of using GitHub for editing the draft. While >> this is a good and helpful tool, it seems it may have led to a gap in >> transparency as to why suggested text was accepted or dropped. If I am >> missing where to look for the answers as to why text was accepted/rejected, >> please provide a pointer. **Otherwise, if we plan to continue using such >> tools (and I think the answer is yes), we'll have to find a way to make >> this process more clear.** >> >> I have a few questions broken out below from the recent feedback. I tried >> to number each question to make this a bit easier to respond. >> >> 1. Text on "who is the intended audience for this draft" >> Eliot Lear had concerns that a particular question Dave Crocker had raised >> did not get a response. The request was to have the draft state for which >> audience the draft was intended. There was at one point text in a Github >> version of the draft that addressed this question, can you let me know why >> it was dropped? From what I can tell, it was dropped silently, so I'd just >> like to understand why, it may be fine, but wanted to check as folks may >> not have been aware that this text was even proposed to answer this >> question. I think this text was from Paul Wouters provided in GitHub. >> Were other opposed to including this information? Does it need to be >> tweaked? >> >> - This document is aimed primarily at protocol designers. It >> - promotes designs in which cryptographic protection against >> - both passive and active attacks works without creating barriers >> - to communication and can be rolled out incrementally as suitably >> - capable systems are deployed. This document is also aimed at >> - operators who set policy for systems that can make use of >> - opportunistic security. >> >> 2. Paul Wouters provided some feedback through the GitHub version between >> 3 and 4. I went through Paul's suggested text and think the difference in >> text could be answered with the question of who is the intended audience. >> Paul's text in some cases simplified the existing text and in other cases, >> he provided specific examples. I think his summary was adapted and >> replaced the abstract (may be wrong on that), so it seems some was accepted. >> >> From my observation, many of the suggestions included examples that were >> not incorporated into version -04. Was there consensus to reduce the >> number of examples? Knowing the answer to this question, would explain why >> many of his suggestions were not accepted without the need for a >> point-by-point response to each proposal of that type. >> >> >> 3. If I am missing where to look for information on the accept/reject of >> edits through the GitHub process, a pointer would be greatly appreciated. >> Here are some specific points from reviewing Paul Woulter's submission >> that I'm not sure had a response, I can't generalize with the above >> catch-all, or I see similar enough text capturing the same point in the >> draft. I appreciate feedback from Paul Hoffman as shepherd or Viktor as >> editor for each of these points: >> >> a. Section 2. Terminology >> The last clause of the sentence was suggested and not accepted in the TOFU >> definition: >> In a protocol, TOFU >> - typically consists of accepting an asserted identity, without >> - authenticating that assertion, and caching a key or credential >> - associated with the identity. >> >> >> b. Section 3. >> Specific suggestions were provided on this section, but it has been >> completely re-worked, so the suggestions were not accepted. This is enough >> of a change that another review may have been warranted. I do like the >> version in draft-04 and think it was a positive improvement. Can you point >> me to agreement on the new text in this section as well as the discussion >> on accepting rejecting text that was proposed? I think this all boils down >> to better processes when tools like GitHub are used for editing. >> >> c. For the text in section 3 on "Maximize security peer by peer", version >> 3 had conditions for failure included and Paul suggested that operational >> consideration should also be listed. It looks like version 4 dropped any >> mention of it failing, can you point to the decision on this particular >> point as it would explain why Paul's suggested text was not accepted. >> Paul's starts with the "-" >> >> Opportunistic >> security strives to maximize security based on the capabilities >> of the peers. Communications traffic should generally be at >> least encrypted. Opportunistic security protocols may refuse to >> communicate with peers for which higher security is expected, >> - but for some reason is not achieved. The conditions under >> - which connections fail should generally be limited to operational >> - errors at one or the other peer or an active attack, so that >> - well-maintained systems rarely encounter problems in normal >> - use of opportunistic security. >> + but for some reason is not achieved. Advertised capability must match >> + reality to ensure the only condition under which there is a failure >> + of communication is when one or both peers are under an active >> attack. >> + >> >> >> d. Paul had also suggested text that looks like I addressed in one of my >> comments where he suggested a "set of CAs". I think we are good on that >> one now. >> >> e. Steve Kent's detailed review >> I have not gone through this point-by-point yet, but Steve also complained >> that he didn't get feedback. It's my observation that Steve tends to give >> very detailed reviews, so this one was no different from other ones (look >> at the SecDir review for one of the JOSE drafts). I do think understanding >> the accept/reject process when GitHub was used would be helpful. Can sets >> of suggestions be grouped to provide an explanation of why they were >> dropped? If not, a point-by point might be helpful. >> >> f. Did I miss anyone that gave a detailed review and didn't get this type >> of feedback? Some was not on list unfortunately. I may add to this list >> if I find some more specific points that I am not sure were addressed. >> >> Thanks! >> >> >> On Mon, Sep 15, 2014 at 10:59 AM, Paul Hoffman >> wrote: >> >>> >>> >>> Thanks for the comments. Those all seem reasonable and within the scope >>> of the rough consensus during IETF Last Call. Viktor will collect these and >>> other IESG comments for a new draft to be posted after the IESG telechat. >>> >>> --Paul Hoffman >> >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Sep 16 09:11:38 2014 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 5AA851A871D; Tue, 16 Sep 2014 09:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 8ktHhdXK5vj3; Tue, 16 Sep 2014 09:11:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D83321A212D; Tue, 16 Sep 2014 09:11:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916161111.9194.31976.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 09:11:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FoZnET6mVZliAV1oCzCGMIiwhjQ Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Spencer Dawkins' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:11:33 -0000 Spencer Dawkins has entered the following ballot position for draft-dukhovni-opportunistic-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "No Objection" primarily on Stephen's assurance that the text changes in this version of the draft are editorial in nature, and I accept his assertion that continued discussion is unlikely to result in improvements to the document. I suspect that continued discussion wouldn't result in the Internet being more resistant to passive monitoring, either, although I'm not one who has enough security clue to assert that in a meaningful way. I agree with the vast majority of Adrian's detailed comments, and think the document would be improved by considering them. I agree with Stephen's statement that publishing this document in the Independent Stream is unlikely to be helpful. From nobody Tue Sep 16 11:12:40 2014 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 EB23D1A8702; Tue, 16 Sep 2014 11:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 5nH1pXfIqqfo; Tue, 16 Sep 2014 11:12:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 473C71A86F9; Tue, 16 Sep 2014 11:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A9B19BE35; Tue, 16 Sep 2014 19:12:35 +0100 (IST) 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 FRKVPvbeS-Gj; Tue, 16 Sep 2014 19:12:34 +0100 (IST) Received: from [10.87.48.5] (unknown [86.42.31.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 282C5BE80; Tue, 16 Sep 2014 19:12:34 +0100 (IST) Message-ID: <54187D91.80508@cs.tcd.ie> Date: Tue, 16 Sep 2014 19:12:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Spencer Dawkins , The IESG References: <20140916161111.9194.31976.idtracker@ietfa.amsl.com> In-Reply-To: <20140916161111.9194.31976.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/JUQaQxgp4Gsan8PzSfxV1upsuH0 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Spencer Dawkins' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 16 Sep 2014 18:12:38 -0000 Hi Spencer, On 16/09/14 17:11, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm balloting "No Objection" primarily on Stephen's assurance that the > text changes in this version of the draft are editorial in nature, and I > accept his assertion that continued discussion is unlikely to result in > improvements to the document. Thanks. > I suspect that continued discussion wouldn't result in the Internet being > more resistant to passive monitoring, either, although I'm not one who > has enough security clue to assert that in a meaningful way. True enough. OTOH, getting done is a good as well. > I agree with the vast majority of Adrian's detailed comments, and think > the document would be improved by considering them. That is the plan. I asked Viktor and paul to hold off detailed responses until we get a (near) full set. Will look over all that tomorrow or Thu before the call though. > I agree with Stephen's statement that publishing this document in the > Independent Stream is unlikely to be helpful. Yup. Cheers, S. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Sep 16 17:17:02 2014 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 015691A6F3E; Tue, 16 Sep 2014 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WVHQEomEE7Nd; Tue, 16 Sep 2014 17:16:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D11A6F41; Tue, 16 Sep 2014 17:16:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917001654.760.43468.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 17:16:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zwT8j__q4hZPhx6x4YrbUvbQHbQ Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Barry Leiba's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 00:16:57 -0000 Barry Leiba has entered the following ballot position for draft-dukhovni-opportunistic-security-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This DISCUSS is on process grounds; I think we have two serious process issues that prevent our claiming that we have rough consensus on the document. 1. The community reviewed and commented on version -03. The IESG is being asked to approve version -04, and is being told there is rough consensus on its content. And yet vesion -04 is essentially a complete rewrite of the document. I understand the assertion that the changes are "just editorial", but that doesn't help: the fact is that the community has *not* reviewed anything close to the version we're being asked to approve. It would be a terrible precedent to say that a document could be rewritten after last call and sent to the IESG for approval that way. I believe that, despite any concern about the usefulness of another last call, this document must get another last call in its current form. To do otherwise would be to trash our rough consensus process. 2. I think the way the document editing was done, and the way the comments were (and were not) responded to was poor, and calls into question what does and doesn't have rough consensus (certainly according to RFC 7282). There were substantive comments that were made that were not explicitly discussed; those comments were then declared "in the rough". I don't believe such declaration can be made purely on the basis of lack of visible support, with no actual discussion or refutation. Dave Crocker and Stephen Kent have both brought up some such issues. I think that re-last-call needs to be accompanied by instructions for people to raise issues that they think they raised before that were not properly discussed, so that there is a chance for them to *be* discussed and, perhaps, for them to be properly declared in the rough once there's real discussion about them. I know some people will think this is a PitA at best, but it should have been done before. An issue tracker, carefully managed, would have been an appropriate tool for a document with this much discussion -- and this much diverse discussion. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I also have two major issues with the document, but note that these are *not* un the DISCUSS portion. Consider this to be strong input, but not part of the blocking process: I'm quite unhappy with the decision to go with "Opportunistic Security" here (rather than "Opportunistic Encryption", since it *is* talking about encryption, or rather than finding another appropriately focused term if there are good reasons not to use "OE"). My sense is that the reasons to use "OS" amount to marketing, but there are solid reasons to use "Encryption" when encryption is central, and not to use the overly broad term "Security" for something that is not actually meant to be broad. I don't like the organization of the document; I don't think it's well written and sufficiently coherent. I know this is vague, but short of having me do yet another rewrite I don't know how to be more specific. The general thing is that topics seem to drift in and out, and the whole document doesn't read as a clear path from one idea, through another, to a set of conclusions. From nobody Tue Sep 16 17:43:34 2014 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 126361A01EF; Tue, 16 Sep 2014 17:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RP_MATCHES_RCVD=-1.652] 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 1MTUir0KFGqu; Tue, 16 Sep 2014 17:43:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44A1A008B; Tue, 16 Sep 2014 17:43:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8366BBE80; Wed, 17 Sep 2014 01:43:27 +0100 (IST) 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 WY0sdEz13wUi; Wed, 17 Sep 2014 01:43:25 +0100 (IST) Received: from [10.87.48.5] (unknown [86.42.31.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78702BE35; Wed, 17 Sep 2014 01:43:25 +0100 (IST) Message-ID: <5418D92D.9080109@cs.tcd.ie> Date: Wed, 17 Sep 2014 01:43:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20140917001654.760.43468.idtracker@ietfa.amsl.com> In-Reply-To: <20140917001654.760.43468.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Ys1UJtX_PJiSGd2e3GBB68WwzZc Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Barry Leiba's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 17 Sep 2014 00:43:33 -0000 Hi Barry, I have some questions about your discuss:-) This is based on my starting point that -04 is not in fact a complete rewrite of -03, but rather a paraphrase plus some new text, both sets of changes matching the list discussion well. I think its entirely fair of me to stick with that assertion, (it being correct:-). You have not provided *any* detail as to why my assertion might be incorrect. So please do provide such detail which I believe is needed to back up your discuss. On 17/09/14 01:16, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This DISCUSS is on process grounds; I think we have two serious process > issues that prevent our claiming that we have rough consensus on the > document. > > 1. The community reviewed and commented on version -03. The IESG is > being asked to approve version -04, and is being told there is rough > consensus on its content. And yet vesion -04 is essentially a complete > rewrite of the document. I understand the assertion that the changes are > "just editorial", but that doesn't help: the fact is that the community > has *not* reviewed anything close to the version we're being asked to > approve. It would be a terrible precedent to say that a document could > be rewritten after last call and sent to the IESG for approval that way. > > I believe that, despite any concern about the usefulness of another last > call, this document must get another last call in its current form. To > do otherwise would be to trash our rough consensus process. If you tell me how this discuss point matches the discuss criteria that'd be great. Perhaps you think "there are unresolved and substantive Last Call comments which the document does not address"? If so, then I think this is the same as your point #2. If not, then please tell me how it does warrant a DISCUSS and is not the same as point#2 since I don't get that. > 2. I think the way the document editing was done, and the way the > comments were (and were not) responded to was poor, and calls into > question what does and doesn't have rough consensus (certainly according > to RFC 7282). There were substantive comments that were made that were > not explicitly discussed; those comments were then declared "in the > rough". I don't believe such declaration can be made purely on the basis > of lack of visible support, with no actual discussion or refutation. > Dave Crocker and Stephen Kent have both brought up some such issues. I think the onus is on you to specify *exactly* which issues you mean, isn't it? It is not sufficient to name other participants in some kind of IOU/bring-me-a-rock discuss I think. So exactly which specific substantive issues here justify your discuss? Separate to the above, I suspect I should start reading the DISCUSS non-criteria probably as I'm strongly reminded of them in reading your discuss points:-) But perhaps you checked that already and if so can tell me why your points do not fall under that heading? (You don't have to do that since I will, and I have no right to insist you do that, so I won't, but if you've thought about it already we may save a bit of time, so I'm asking:-) Thanks, S. > I think that re-last-call needs to be accompanied by instructions for > people to raise issues that they think they raised before that were not > properly discussed, so that there is a chance for them to *be* discussed > and, perhaps, for them to be properly declared in the rough once there's > real discussion about them. I know some people will think this is a PitA > at best, but it should have been done before. An issue tracker, > carefully managed, would have been an appropriate tool for a document > with this much discussion -- and this much diverse discussion. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I also have two major issues with the document, but note that these are > *not* un the DISCUSS portion. Consider this to be strong input, but not > part of the blocking process: > > I'm quite unhappy with the decision to go with "Opportunistic Security" > here (rather than "Opportunistic Encryption", since it *is* talking about > encryption, or rather than finding another appropriately focused term if > there are good reasons not to use "OE"). My sense is that the reasons to > use "OS" amount to marketing, but there are solid reasons to use > "Encryption" when encryption is central, and not to use the overly broad > term "Security" for something that is not actually meant to be broad. > > I don't like the organization of the document; I don't think it's well > written and sufficiently coherent. I know this is vague, but short of > having me do yet another rewrite I don't know how to be more specific. > The general thing is that topics seem to drift in and out, and the whole > document doesn't read as a clear path from one idea, through another, to > a set of conclusions. > > From nobody Wed Sep 17 06:28:10 2014 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 8DE851A01CB; Wed, 17 Sep 2014 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 Dv8f_FW9L6mD; Wed, 17 Sep 2014 06:28:07 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BBC1A0113; Wed, 17 Sep 2014 06:28:07 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 66A451B86F2; Wed, 17 Sep 2014 06:28:07 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 1D94E53E074; Wed, 17 Sep 2014 06:28:07 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Sep 2014 06:28:07 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5418D92D.9080109@cs.tcd.ie> Date: Wed, 17 Sep 2014 09:27:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <886CB571-6037-40A1-9279-A63DFD0FFC1E@nominum.com> References: <20140917001654.760.43468.idtracker@ietfa.amsl.com> <5418D92D.9080109@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/T3fSlsk0KK7EQ01JBLZVUWpFFWc Cc: Barry Leiba , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Barry Leiba's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 17 Sep 2014 13:28:08 -0000 On Sep 16, 2014, at 8:43 PM, Stephen Farrell = wrote: > You have not provided *any* detail as to why > my assertion might be incorrect. So please do provide such detail > which I believe is needed to back up your discuss. Presumably you already did this as part of the consensus evaluation. = Is it really so unreasonable for Barry to ask you to show your work? From nobody Wed Sep 17 06:57:17 2014 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 03F5B1A0436; Wed, 17 Sep 2014 06:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 2BYadN-l8KxY; Wed, 17 Sep 2014 06:57:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B1F7C1A0412; Wed, 17 Sep 2014 06:57:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A4066BE20; Wed, 17 Sep 2014 14:57:06 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjvVwHq7P9EQ; Wed, 17 Sep 2014 14:57:06 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FAF5BDFA; Wed, 17 Sep 2014 14:57:06 +0100 (IST) Message-ID: <54199333.9040902@cs.tcd.ie> Date: Wed, 17 Sep 2014 14:57:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Ted Lemon References: <20140917001654.760.43468.idtracker@ietfa.amsl.com> <5418D92D.9080109@cs.tcd.ie> <886CB571-6037-40A1-9279-A63DFD0FFC1E@nominum.com> In-Reply-To: <886CB571-6037-40A1-9279-A63DFD0FFC1E@nominum.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/9uqUl1wTt_YlW3xmc2HBe75dvh8 Cc: Barry Leiba , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Barry Leiba's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 17 Sep 2014 13:57:10 -0000 Hi Ted, On 17/09/14 14:27, Ted Lemon wrote: > On Sep 16, 2014, at 8:43 PM, Stephen Farrell > wrote: >> You have not provided *any* detail as to why my assertion might be >> incorrect. So please do provide such detail which I believe is >> needed to back up your discuss. > > Presumably you already did this as part of the consensus evaluation. Yes. As can you. This is unfortunately one where to arrive at your own position you need to go check the list traffic [1] and read (as opposed to be shocked by the volume of:-) the diffs between -03 and -04. [2] The list traffic does include summaries of the LC at a couple of places. [3,4] Unfortunately, it also includes a lot of repetition before and after those messages. And to be clear, its of course just fine if you do that and disagree with my conclusions. > Is it really so unreasonable for Barry to ask you to show your work? Barry has not asked for that. He has asserted that there are DISCUSS-worthy problems but has so far provided nothing but that assertion that I can see. There are also the DISCUSS non-criteria which are relevant in particular for DEFERred drafts and IOU-like discusses as seems to me to clearly be the case here for Barry's discuss point#2. And I have asked about his first discuss point as I'm not clear about how it meets the DISCUSS criteria either. (It might or might not depending on what Barry means, I think clarifying first that its DISCUSS worthy and why will get us to closure faster.) Cheers, S. [1] https://mailarchive.ietf.org/arch/search/?email_list=ietf&q=opportunistic-security [2] https://tools.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-04.txt [3] https://www.ietf.org/mail-archive/web/ietf/current/msg89139.html [4] https://www.ietf.org/mail-archive/web/ietf/current/msg89280.html > From nobody Wed Sep 17 07:42:10 2014 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 48CEC1A04A6; Wed, 17 Sep 2014 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.653 X-Spam-Level: X-Spam-Status: No, score=-8.653 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=-1.652, 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 Q-neyxag7TFk; Wed, 17 Sep 2014 07:42:06 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5091A04A1; Wed, 17 Sep 2014 07:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1410964926; x=1442500926; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KYMWGZxiMAd27mO05l+PdpqnEsq1w8w8zKaN8RMiUag=; b=mpGh3SioJm9tVbR6Gq17W6vLmYb34Zu1+45PVqNrEbfkqeYV4GuupWge ax3xe3FNMwOZpg6Qz4t4zg0Wfn5CU22d/Kv/+9qF21l9CblGXrm5Ize4C QVxub83wkjdcEGbjBJNjuaV7g2puMO4C2B8pl+OaWWQwQAMWffFWC6356 c=; X-IronPort-AV: E=McAfee;i="5600,1067,7563"; a="74320640" Received: from unknown (HELO Ironmsg03-R.qualcomm.com) ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 17 Sep 2014 07:42:06 -0700 X-IronPort-AV: E=Sophos;i="5.04,540,1406617200"; d="scan'208";a="752545600" Received: from nasanexhc03.na.qualcomm.com ([10.46.56.181]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Sep 2014 07:42:05 -0700 Received: from nasanexm01a.na.qualcomm.com (129.46.53.228) by NASANEXHC03.na.qualcomm.com (10.46.56.181) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 17 Sep 2014 07:42:05 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by nasanexm01a.na.qualcomm.com (129.46.53.228) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 17 Sep 2014 07:42:04 -0700 Message-ID: <54199D96.3090009@qti.qualcomm.com> Date: Wed, 17 Sep 2014 09:41:26 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <20140917001654.760.43468.idtracker@ietfa.amsl.com> <5418D92D.9080109@cs.tcd.ie> <886CB571-6037-40A1-9279-A63DFD0FFC1E@nominum.com> <54199333.9040902@cs.tcd.ie> In-Reply-To: <54199333.9040902@cs.tcd.ie> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.46.200.111) To nasanexm01a.na.qualcomm.com (129.46.53.228) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/WcDyTiKJhFudCvzVFLqAhpEPGZk Cc: Ted Lemon , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, Barry Leiba , saag@ietf.org Subject: Re: [saag] Barry Leiba's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 17 Sep 2014 14:42:08 -0000 On 9/17/14 8:57 AM, Stephen Farrell wrote: >> Is it really so unreasonable for Barry to ask you to show your work? >> > Barry has not asked for that. He has asserted that there are > DISCUSS-worthy problems but has so far provided nothing but > that assertion that I can see. > No, that's not what Barry's first point says. It says, "You haven't shown your work." It's not the same as point #2. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Sep 17 07:55:47 2014 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 626601A019B; Wed, 17 Sep 2014 07:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-6ZSg6XFhpA; Wed, 17 Sep 2014 07:55:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810881A0141; Wed, 17 Sep 2014 07:55:39 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8HEtSMp020653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Sep 2014 07:55:31 -0700 Message-ID: <5419A0DD.6080308@dcrocker.net> Date: Wed, 17 Sep 2014 07:55:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Ted Lemon References: <20140917001654.760.43468.idtracker@ietfa.amsl.com> <5418D92D.9080109@cs.tcd.ie> <886CB571-6037-40A1-9279-A63DFD0FFC1E@nominum.com> <54199333.9040902@cs.tcd.ie> In-Reply-To: <54199333.9040902@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 17 Sep 2014 07:55:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Uy0p-enlMS1skzs4Er0FORhxo1k Cc: Barry Leiba , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Barry Leiba's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:55:41 -0000 On 9/17/2014 6:57 AM, Stephen Farrell wrote: >> Presumably you already did this as part of the consensus evaluation. > Yes. As can you. This is unfortunately one where to arrive at your > own position you need to go check the list traffic [1] The above is a summary that demonstrates merely one of the many examples of having basic concerns be ignored in this process. It contains pointers to other postings that were ignored or dismissed out of hand. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Sep 17 11:06:39 2014 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 5A89B1A0842; Wed, 17 Sep 2014 11:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8] 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 eqx9sjh4LPWX; Wed, 17 Sep 2014 11:06:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 360731A0721; Wed, 17 Sep 2014 11:06:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917180633.7822.23633.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 11:06:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GBlxCcU2tZGOFTfdCtOQLablfNw Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Alissa Cooper's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:06:35 -0000 Alissa Cooper has entered the following ballot position for draft-dukhovni-opportunistic-security-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I think it is a helpful contribution. On process, prior to taking a deep dive into the LC mailing list traffic and talking with the AD, shepherd, and author, I was originally skeptical about whether this document had achieved rough consensus and whether IETF process had been followed effectively. After having taken those steps, I am convinced that both are true. I also now understand why the term "opportunistic security" was chosen and believe there is rough consensus in support of using that term. However, for a document that is quite short and a concept that is fairly straightforward, I find this document really difficult to understand in places. I've listed the bits that are so ambiguous that I think readers will not understand them as DISCUSS points and other comments as COMMENT points. DISCUSS: o Section 1: "For a particular protocol or application, if and when all but a negligible fraction of peers support encryption, the baseline security may be raised from cleartext to always require encryption. Similarly, once support for authentication is near-universal, the baseline may be raised to always require authentication." I agree with Adrian that it is unclear what this means. And in fact it seems to contradict other language in the document by assuming that a protocol has one mode of operation for *all* peers. I thought one of the goals of OS was that within any single protocol interaction or within any single group of peers, the level of encryption used could be negotiated up to the lowest common denominator among the peers. Perhaps this would be clearer if it emphasized that the default mode for a particular protocol or application might be chosen to be cleartext, unauthenticated encryption, or authenticated encryption, with the ability for peers to negotiate up if they are capable. o Section 1: "In essence, OS is employed when one might otherwise settle for cleartext (or the minimum protection possible if the protocol is always encrypted)." I don't understand the parenthetical, either in substance or grammar. o Section 1: "For example, a policy might require authenticated, encrypted communication, in contrast to the default OS security policy." This sentence presents another reason why the previous paragraph does not make sense. The previous paragraph seems to say that in some cases, the default OS security policy could be to use authenticated encryption. In those cases, this sentence is not correct. o Section 1.2: I find the document's guidance about the extent to which OS protocols "work behind the scenes" to be confusing. There is this text in this section: "OS protocols work transparently behind the scenes, without disrupting communication. When less than complete protection is negotiated, there is no need to prompt the user with "your security may be degraded, please click OK" dialogs. The negotiated protection is as good as can be expected. Even if not comprehensive, it is often better than the traditional outcome of either "no protection" or "communications failure"." And then in Section 3 there is this: "No misrepresentation of security: Unauthenticated, encrypted communication must not be misrepresented to users or in application logs of non-interactive applications as equivalent to authenticated, encrypted communication." The bit about working "behind the scenes" and not prompting the user seems to me to be distinct from the issue of misrepresenting security. That is, (1) whether the user is proactively informed of the extent to which his communications are protected, (2) whether the user is able to find out about that protection on his own, and (3) whether the information provided to the user about that protection is accurate are three separate questions. I find that Section 1.2 argues against (1), although this is not elevated to the level of a "design principle" as it is not included in Section 3. Section 3 argues in favor of (3) -- providing accurate information -- and includes that as a design principle. I believe the document is silent about (2). I get the sense that (1) is viewed by people who worked on this document as an important by-product of wider deployment of OS, so I would have expected support for it to be more explicit in the document, rather than somewhat latent as it is. If there were a fuller discussion of (1), I would also expect (2) to be addressed, as it is natural to ask just how "behind the scenes" OS protocols are expected to be (as Adrian pointed out). This seems like a fairly significant gap in the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- o Section 1: s/For authentication based on peer capabilities to protect against MiTM attacks/For authentication based on peer capabilities to be able to protect against MiTM attacks/ (FWIW, the above makes more sense to me than Adrian's suggested edit to the same sentence.) o Section 1.1: General comment: It is really unclear what the point of this section is and why this set of paragraphs is strung together as one section. I would suggest adding an opening paragraph along the lines of "This section provides some background about historic and current challenges associated with the use of encryption on the Internet, illustrated using discussion of the Web PKI." o Section 1.1: s/With so many certification authorities, which not everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA./With so many certification authorities, all of which are not trusted by all entities, the communicating parties don't always agree on a mutually trusted CA./ o Section 1.1: "In interactive applications, security warnings are all too frequent, and end-users learn to actively ignore security problems" This point is orthogonal to the rest of the paragraph to which it is attached. The fact that choices were made to pop security warnings was separate from other choices made about the web PKI. It doesn't quite make sense to me why this is mushed together with a paragraph about "cost and management burdens." o Section 1.1: "For encryption to be used more broadly, authentication needs to be optional. The use of encryption defends against pervasive monitoring and other passive attacks (which are employed not only by nation states). Even unauthenticated, encrypted communication (defined below) is preferable to cleartext." This seems like it should be the first paragraph of Section 1.2. It is rather out of place in Section 1.2. o Section 3: "OS offers an incremental path to authenticated, encrypted communication in the future, as suitable authentication technologies are deployed." As in Section 1, this text seems to assume one mode of operation for a particular protocol. What about protocols that can already support authenticated encryption? Doesn't OS offer an incremental path towards using that mode right now, not in the future, for peers that already support it? o Section 3: s/Communication should generally be at least encrypted./At a minimum, communication should generally be encrypted without authentication./ (I think this was the intention here, although I'm not completely sure what "at least" means.) From nobody Wed Sep 17 12:32:27 2014 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 418611A0ACD; Wed, 17 Sep 2014 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 WXEg1Bu0hsOJ; Wed, 17 Sep 2014 12:32:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C98BD1A0432; Wed, 17 Sep 2014 12:32:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3B019BE03; Wed, 17 Sep 2014 20:32:19 +0100 (IST) 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 U-_U4Iitt4WN; Wed, 17 Sep 2014 20:32:17 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.59.185]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8DAFBE0D; Wed, 17 Sep 2014 20:32:16 +0100 (IST) Message-ID: <5419E1C0.3060005@cs.tcd.ie> Date: Wed, 17 Sep 2014 20:32:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20140917180633.7822.23633.idtracker@ietfa.amsl.com> In-Reply-To: <20140917180633.7822.23633.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/e0dGqmTXsBIk3G31uvGXbTMmo_8 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Alissa Cooper's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 17 Sep 2014 19:32:22 -0000 Thanks Alissa, Back to you on those tomorrow. Nothing there seems mad to me anyway:-) S On 17/09/14 19:06, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks to everyone who worked on this document. I think it is a helpful > contribution. > > On process, prior to taking a deep dive into the LC mailing list traffic > and talking with the AD, shepherd, and author, I was originally skeptical > about whether this document had achieved rough consensus and whether IETF > process had been followed effectively. After having taken those steps, I > am convinced that both are true. > > I also now understand why the term "opportunistic security" was chosen > and believe there is rough consensus in support of using that term. > > However, for a document that is quite short and a concept that is fairly > straightforward, I find this document really difficult to understand in > places. I've listed the bits that are so ambiguous that I think readers > will not understand them as DISCUSS points and other comments as COMMENT > points. > > DISCUSS: > > o Section 1: > "For a particular protocol or application, if and when all but a > negligible fraction of peers support encryption, the baseline > security may be raised from cleartext to always require encryption. > Similarly, once support for authentication is near-universal, the > baseline may be raised to always require authentication." > > I agree with Adrian that it is unclear what this means. And in fact it > seems to contradict other language in the document by assuming that a > protocol has one mode of operation for *all* peers. I thought one of the > goals of OS was that within any single protocol interaction or within any > single group of peers, the level of encryption used could be negotiated > up to the lowest common denominator among the peers. Perhaps this would > be clearer if it emphasized that the default mode for a particular > protocol or application might be chosen to be cleartext, unauthenticated > encryption, or authenticated encryption, with the ability for peers to > negotiate up if they are capable. > > > o Section 1: > "In essence, OS is employed when one might otherwise settle for > cleartext > (or the minimum protection possible if the protocol is always > encrypted)." > > I don't understand the parenthetical, either in substance or grammar. > > > o Section 1: > "For example, a policy might require authenticated, encrypted > communication, in contrast to the default OS security policy." > > This sentence presents another reason why the previous paragraph does not > make sense. The previous paragraph seems to say that in some cases, the > default OS security policy could be to use authenticated encryption. In > those cases, this sentence is not correct. > > > o Section 1.2: > I find the document's guidance about the extent to which OS protocols > "work behind the scenes" to be confusing. There is this text in this > section: > > "OS protocols work > transparently behind the scenes, without disrupting communication. > > When less than complete protection is negotiated, there is no need to > prompt the user with "your security may be degraded, please click OK" > dialogs. The negotiated protection is as good as can be expected. > Even if not comprehensive, it is often better than the traditional > outcome of either "no protection" or "communications failure"." > > And then in Section 3 there is this: > > "No misrepresentation of security: Unauthenticated, encrypted > communication must not be misrepresented to users or in > application logs of non-interactive applications as equivalent to > authenticated, encrypted communication." > > The bit about working "behind the scenes" and not prompting the user > seems to me to be distinct from the issue of misrepresenting security. > That is, (1) whether the user is proactively informed of the extent to > which his communications are protected, (2) whether the user is able to > find out about that protection on his own, and (3) whether the > information provided to the user about that protection is accurate are > three separate questions. I find that Section 1.2 argues against (1), > although this is not elevated to the level of a "design principle" as it > is not included in Section 3. Section 3 argues in favor of (3) -- > providing accurate information -- and includes that as a design > principle. I believe the document is silent about (2). > > I get the sense that (1) is viewed by people who worked on this document > as an important by-product of wider deployment of OS, so I would have > expected support for it to be more explicit in the document, rather than > somewhat latent as it is. If there were a fuller discussion of (1), I > would also expect (2) to be addressed, as it is natural to ask just how > "behind the scenes" OS protocols are expected to be (as Adrian pointed > out). This seems like a fairly significant gap in the document. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > o Section 1: > s/For authentication based on peer capabilities to protect > against MiTM attacks/For authentication based on peer capabilities to > be able to protect against MiTM attacks/ > > (FWIW, the above makes more sense to me than Adrian's suggested edit to > the same sentence.) > > > o Section 1.1: > General comment: It is really unclear what the point of this section is > and why this set of paragraphs is strung together as one section. I would > suggest adding an opening paragraph along the lines of "This section > provides some background about historic and current challenges associated > with the use of encryption on the Internet, illustrated using discussion > of the Web PKI." > > > o Section 1.1: > s/With so many certification authorities, which not everyone is willing > to trust, > the communicating parties don't always agree on a mutually trusted > CA./With so many certification authorities, all of which are not > trusted by all entities, the communicating parties don't always agree on > a mutually trusted > CA./ > > > o Section 1.1: > "In interactive > applications, security warnings are all too frequent, and end-users > learn to actively ignore security problems" > > This point is orthogonal to the rest of the paragraph to which it is > attached. The fact that choices were made to pop security warnings was > separate from other choices made about the web PKI. It doesn't quite make > sense to me why this is mushed together with a paragraph about "cost and > management burdens." > > > o Section 1.1: > "For encryption to be used more broadly, authentication needs to be > optional. The use of encryption defends against pervasive monitoring > and other passive attacks (which are employed not only by nation > states). Even unauthenticated, encrypted communication (defined > below) is preferable to cleartext." > > This seems like it should be the first paragraph of Section 1.2. It is > rather out of place in Section 1.2. > > > o Section 3: > "OS offers an incremental path to authenticated, encrypted communication > in the > future, as suitable authentication technologies are deployed." > > As in Section 1, this text seems to assume one mode of operation for a > particular protocol. What about protocols that can already support > authenticated encryption? Doesn't OS offer an incremental path towards > using that mode right now, not in the future, for peers that already > support it? > > > o Section 3: > s/Communication should generally > be at least encrypted./At a minimum, communication should > generally > be encrypted without authentication./ > > (I think this was the intention here, although I'm not completely sure > what "at least" means.) > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Wed Sep 17 14:31:46 2014 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 EBB951A6F85; Wed, 17 Sep 2014 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 cRAEEB1DDf65; Wed, 17 Sep 2014 14:31:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 836FA1A0AF6; Wed, 17 Sep 2014 14:31:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9BCC1BE1C; Wed, 17 Sep 2014 22:31:20 +0100 (IST) 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 cLjqTsKSNUMa; Wed, 17 Sep 2014 22:31:17 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.59.185]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A4E74BDFE; Wed, 17 Sep 2014 22:31:17 +0100 (IST) Message-ID: <5419FDA3.9060305@cs.tcd.ie> Date: Wed, 17 Sep 2014 22:31:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Alia Atlas , The IESG References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> In-Reply-To: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/YId032WfWJ5UZoz4ymD_Bq1v4dE Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 17 Sep 2014 21:31:41 -0000 On 17/09/14 22:18, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > First, I am quite supportive of a revision of this document going > forward. It provides a pragmatic and useful mindset towards mitigating > pervasive monitoring. > > However, I do support Barry's Discuss. I have not followed all of the > discussion on the IETF list about the draft, but enough to feel > uncomfortable about the interactions. There can certainly be rough > consensus but the reaction seems to be more about transparency of what > and why things were changes. Fair enough. We'll be chatting about that tomorrow for sure:-) > Secondly, I am not fond of the term "Opportunistic Security" as compared > to "Opportunistic Encryption" if encryption is really all that is meant. > For instance, does OS have the ability to improve over clear-text to > prevent replay attacks? That's something that encryption alone doesn't > necessarily provide; of course, it can also be protocol-specific. IF > this is about OS and not OE, I would find it useful to be clearer about > the dimensions/aspects of security that can be opportunistic. It > definitely reads like this is only about opportunistic encryption and > nothing else. AEAD ciphers, even with unauthenticated endpoints (i.e. following the OS pattern) can provide some replay protection, depending on how they interact with the protocol in question and how counters/nonces are handled. So yes some form of replay protection can be part of OS in some cases. Cheers, S. > > From nobody Wed Sep 17 19:35:27 2014 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 218731A0079 for ; Wed, 17 Sep 2014 19:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZMcCl_iy9yK for ; Wed, 17 Sep 2014 19:35:19 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C311A6FF6 for ; Wed, 17 Sep 2014 19:35:18 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id b12so254074lbj.25 for ; Wed, 17 Sep 2014 19:35:17 -0700 (PDT) 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=KCFnKJesXwrLeewlbpsHUE/VdQT3kclPuuydYZEg2a8=; b=DFt85IBFOleI2DkZWWUqmGRLtkKnaWD0+0ImxBYuKm8rf9KNoPV6ELNJ6pCdixyCSx 92zfnjixCh84FGtWA4Gr9/zxooSXj3JAI4pgmyjrcYWKmpNVAnmrFMHGFxc8MzjBCZOj VU7c3vR9sYOHIY1eytC5MiE+QBbEsBAuLdbptrZ6zWe3x583qPtW5joDANyW6GM5PZmS JezfnGRBPcF/GeVWg/nYdUafIOBhl0OjwhUFSSBKKtlHGaLUwntp8y7nog74szLmFKGQ j/ghEAU2Lf858keUUgNBmeKxSzUTeeP2Zgwbm/wcmnRe29n5yKQecGVxOnK7Cpbbt3T6 KGPQ== X-Gm-Message-State: ALoCoQmNRVawQyOHNjogQ8qASAlXSVkmx8BsZPGJohk0hsZL4FGAl0EMRq4tlyQxImjLHCd5h8F8 MIME-Version: 1.0 X-Received: by 10.152.7.8 with SMTP id f8mr1431065laa.27.1411007717236; Wed, 17 Sep 2014 19:35:17 -0700 (PDT) Received: by 10.25.159.84 with HTTP; Wed, 17 Sep 2014 19:35:17 -0700 (PDT) In-Reply-To: <54180D8E.6070706@cs.tcd.ie> References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> Date: Wed, 17 Sep 2014 22:35:17 -0400 Message-ID: From: Richard Barnes To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2a0f4c2f33305034dd53f Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3WZeUQ_jVPOTNGq6D90gEHcfy64 Cc: Martin Stiemerling , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, IETF SAAG Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 02:35:23 -0000 --001a11c2a0f4c2f33305034dd53f Content-Type: text/plain; charset=UTF-8 On Tue, Sep 16, 2014 at 6:14 AM, Stephen Farrell wrote: > > Hi Martin, > > On 16/09/14 10:37, Martin Stiemerling wrote: > > Martin Stiemerling has entered the following ballot position for > > draft-dukhovni-opportunistic-security-04: No Record > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I am not done with my review, but in the meanwhile I have question: > > > > How does this draft related to the old Better-Than-Nothing Security > > (btns) working group [1] and their output? > > I think its fair to say this LC discussion involved some of the > same protagonists and some of the same arguments. > > Hopefully this RFC would short-circuit a part of the debate > that happened back then (*) but more recently in the httpbis WG. > There was also a bit of that debate in chartering tcpinc. > As long as we're clear that the way this RFC would help is to avoid terminology confusion -- not to imply that OS is necessarily the only or preferred option. Because I don't think there's consensus on the latter. The debate that this ought short-circuit is the part about > the overall legitimacy of the approach. So this draft should > save time, energy and good-will when an OS approach is proposed > for other protocols - that part of the discussion seems to me > at least to be contentious, so that can be a non-trivial saving. > > Functionally, I think one could describe the output from BTNS > as following the OS design pattern, but not that successfully. > (The lack of success conclusion being based on the lack of > deployment, it'd probably not be productive to try analyse > the reasons for that further right now - see below.) > My understanding is that BTNS ran up against the major hard problem for OS -- how do you combine it with real, non-opportunistic security? (Without enabling downgrade attacks.) For better or worse, IPsec was built to incorporate a very robust access control model, and IIRC the main difficulty for BTNS was figuring out how to integrate unauthenticated associations with that model. The same problem exists in other forms for other protocols, and requires application-layer help. In the HTTP context, the client can tell whether to operate in opportunistic mode based on HTTP information, such as the scheme of the request ("http:" vs. "https:"). Other protocols will need other mechanisms. All of which seems to suggest that BTNS-bis is not all that likely to have better success, as long as it is restricted to operating at the IPsec layer. --Richard Some of those involved in BTNS have been working on another go > at applying the OS approach to IPsec. That work has not yet > been chartered anywhere but we have had a couple of updates > at saag sessions [2] ([2] btw doesn't use the OS term - it > was done while we were still flailing about with imperfect > term selection;-) If that work got sufficient traction to be > chartered, then this draft should help with that, again by > legitimising the design pattern. The discussion as to why > BTNS wasn't successful, and why some proposed new work might > succeed, would of course still need to be had at chartering > time. > > Hope that covers it, > Cheers, > S. > > [2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf > > (*) I wasn't involved in BTNS really, other than to watch the > fireworks from the sidelines. From that perspective, I think that > history probably explains some of the difficulty getting agreement > with this draft. > > > > > > [1] http://www.ietf.org/wg/concluded/btns.html > > > > > > --001a11c2a0f4c2f33305034dd53f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 16, 2014 at 6:14 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hi Martin,

On 16/09/14 10:37, Martin Stiemerling wrote:
> Martin Stiemerling has entered the following ballot position for
> draft-dukhovni-opportunistic-security-04: No Record
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-dukhov= ni-opportunistic-security/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I am not done with my review, but in the meanwhile I have question: >
> How does this draft related to the old Better-Than-Nothing Security > (btns) working group [1] and their output?

I think its fair to say this LC discussion involved some of the=
same protagonists and some of the same arguments.

Hopefully this RFC would short-circuit a part of the debate
that happened back then (*) but more recently in the httpbis WG.
There was also a bit of that debate in chartering tcpinc.
<= div>
As long as we're clear that the way this RFC would h= elp is to avoid terminology confusion -- not to imply that OS is necessaril= y the only or preferred option.=C2=A0 Because I don't think there's= consensus on the latter.
=C2=A0

The debate that this ought short-circuit is the part about
the overall legitimacy of the approach. So this draft should
save time, energy and good-will when an OS approach is proposed
for other protocols - that part of the discussion seems to me
at least to be contentious, so that can be a non-trivial saving.

Functionally, I think one could describe the output from BTNS
as following the OS design pattern, but not that successfully.
(The lack of success conclusion being based on the lack of
deployment, it'd probably not be productive to try analyse
the reasons for that further right now - see below.)
<= br>
My understanding is that BTNS ran up against the major hard p= roblem for OS -- how do you combine it with real, non-opportunistic securit= y?=C2=A0 (Without enabling downgrade attacks.)=C2=A0 For better or worse, I= Psec was built to incorporate a very robust access control model, and IIRC = the main difficulty for BTNS was figuring out how to integrate unauthentica= ted associations with that model.

The same problem exists= in other forms for other protocols, and requires application-layer help.= =C2=A0 In the HTTP context, the client can tell whether to operate in oppor= tunistic mode based on HTTP information, such as the scheme of the request = ("http:" vs. "https:").=C2=A0 Other protocols will need= other mechanisms.
=C2=A0
All of which seems to sug= gest that BTNS-bis is not all that likely to have better success, as long a= s it is restricted to operating at the IPsec layer.

--Ric= hard


Some of those involved in BTNS have been working on another go
at applying the OS approach to IPsec. That work has not yet
been chartered anywhere but we have had a couple of updates
at saag sessions [2] ([2] btw doesn't use the OS term - it
was done while we were still flailing about with imperfect
term selection;-) If that work got sufficient traction to be
chartered, then this draft should help with that, again by
legitimising the design pattern. The discussion as to why
BTNS wasn't successful, and why some proposed new work might
succeed, would of course still need to be had at chartering
time.

Hope that covers it,
Cheers,
S.

[2] https://www.ietf.org/proceedings/89/slides/slides-89= -saag-4.pdf

(*) I wasn't involved in BTNS really, other than to watch the
fireworks from the sidelines. From that perspective, I think that
history probably explains some of the difficulty getting agreement
with this draft.


>
> [1] http://www.ietf.org/wg/concluded/btns.html
>
>


--001a11c2a0f4c2f33305034dd53f-- From nobody Wed Sep 17 21:41:53 2014 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 322C81A6F64; Wed, 17 Sep 2014 21:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 qREYg9qjJ50W; Wed, 17 Sep 2014 21:41:45 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AB51C1A010A; Wed, 17 Sep 2014 21:41:45 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 7C93E21DE58; Wed, 17 Sep 2014 21:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=sgQDWtQQiNnZog RlZcYowuCjldg=; b=C/A0A8HzxVe81gmIUeM0Jt4ED8zlBifKFBJFLAWIWhJV4b lGMJX6FUVlCHcJJQTP0SJ5jpjOBjRr9IHQPw0l6fV79MesdF8ffqARzzlsE67Caj CBC5uiJyiDG7YfiX2qhpG6eQdOeNiw3ndm6bY3XqfZ0TgZ5OZjpyW59M71uSE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id E646D21DE57; Wed, 17 Sep 2014 21:41:44 -0700 (PDT) Date: Wed, 17 Sep 2014 23:41:44 -0500 From: Nico Williams To: Richard Barnes Message-ID: <20140918044141.GD4273@localhost> References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@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.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0pqx2Q_HJhiopUkwEWBhtTRPqwI Cc: Martin Stiemerling , IETF SAAG , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 04:41:47 -0000 [Sorry to butt in. I'm responding only to the sub-thread about BTNS, a) to correct the record, b) because the differences and similarities between the security model in BTNS and the security model in OS that are relevant here. I will butt out immediately after. -Nico] On Wed, Sep 17, 2014 at 10:35:17PM -0400, Richard Barnes wrote: > On Tue, Sep 16, 2014 at 6:14 AM, Stephen Farrell > wrote: > > On 16/09/14 10:37, Martin Stiemerling wrote: > > Functionally, I think one could describe the output from BTNS > > as following the OS design pattern, but not that successfully. - BTNS requires the use of ESP/AH IF the peer is discovered to support IPsec. - BTNS itself provides no other way of adversiting discovering IPsec capabilities of peers than attempting to establish SAs. (Of course, additional methods of advertisement/discovery are not precluded.) - BTNS does not crowd out the standard IPsec model, so that if you must authenticate a peer, then you must authenticate it. In a way BTNS is very much like OS, but the focus was different. Speaking for myself, my focus was getting IPsec channels that could be used with channel binding. Completely missing from this picture was the idea that external systems like DANE could be used to provide server authentication to mostly anonymous clients, and that this could be used to "raise the security floor". But BTNS is not incompatible with OS. The problem with BTNS is explained below. > > (The lack of success conclusion being based on the lack of > > deployment, it'd probably not be productive to try analyse > > the reasons for that further right now - see below.) If there's a perception that we tried this (this == opportunism) with BTNS and we failed, then the failure needs to be explained. Here's my explanation: BTNS severely exacerbates an active attack weakness in the IPsec security model that must be addressed via RFC5660 (connection latching) or Leap-of-Faith/TOFU learnign of peer {IP address, public key}s. The latter not being realistic (because unlike SSH, the binding is to addresses, not names), only the former could get us out of this bind. Connection latching by and large didn't get implemented. This is the root cause of the real BTNS deployment failure. Why didn't connection latching get implemented? Because it requires upper layers like TCP to interact with IPsec. This means more kernel-land code in general purpose OSes, and more interfaces between layers as well as extensions to PFKEY and similar. Such work is not exactly portable, thus the effort needed to implement and use BTNS securely is larger than the effort needed, say, use TLS more.) > My understanding is that BTNS ran up against the major hard problem for OS > -- how do you combine it with real, non-opportunistic security? (Without > enabling downgrade attacks.) For better or worse, IPsec was built to > incorporate a very robust access control model, and IIRC the main > difficulty for BTNS was figuring out how to integrate unauthenticated > associations with that model. Your understanding is not correct. See above. Particularly worth noting is that IPsec does NOT really have a "robust" access control model because IPsec authenticates IP _packets_ (therefore it provides no integrity protection to _logical packet flows_) and IP _addresses_ (therefore IPsec access controls are inconvenient at the very least, requiring massive machinery to produce maintain, distribute, and synchronize large configurations). RFC5660 is all about extending IPsec to protect logical packet _flows_ from peer identity changes. E.g., a peer got renumbers, another node took the old IP address, and both have certs from the same issuer: why should the new node be able to insert itself into extant packet flows with the old peer? what if the new peer DoSed the old peer of the network and the old peer's address was dynamically allocated? IPsec says: whatever, keep going, who cares. Connection latching says: the new peer can't neither get nor inject packets into those flows. > The same problem exists in other forms for other protocols, and requires > application-layer help. In the HTTP context, the client can tell whether > to operate in opportunistic mode based on HTTP information, such as the > scheme of the request ("http:" vs. "https:"). Other protocols will need > other mechanisms. IPsec by and large has no such input from applications, thus IPsec can only be mandatory (by local policy) or opportunistic. IPsec normally only had mandatory policy. BTNS added opportunistic policy. > All of which seems to suggest that BTNS-bis is not all that likely to have > better success, as long as it is restricted to operating at the IPsec layer. BTNS does not need a -bis. It could use: a) implementation of RFC5660, b) standardized socket APIs (like Dan McDonald's IP_SEC_OPT) enabling applications to request/discover BTNS, c) additional APIs that make it possible to use DANE with _hostnames_ (as opposed to IP addresses, as in IPsec OE). (c) would put IPsec on the same level as SMTP w/ TLS + OS. Supposing we were serious about end-to-end IPsec (as opposed to VPN and other tunnelling applications) we would insist on having a way to tie security to hostnames. With BTNS _my_ vision was to use channel binding, but DANE is clearly even mo' betta if we want widespread adoption. (For example, apps might supply DANE TLSA RR RDATA to TCP via a socket option.) Nico -- From nobody Thu Sep 18 01:39:18 2014 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 61FB21A86F7; Thu, 18 Sep 2014 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 2fgKnsweBt9a; Thu, 18 Sep 2014 01:39:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D3D0A1A0402; Thu, 18 Sep 2014 01:38:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49C73BE02; Thu, 18 Sep 2014 09:38:33 +0100 (IST) 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 WuaDvySfsaWR; Thu, 18 Sep 2014 09:38:31 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.59.185]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C308EBDD8; Thu, 18 Sep 2014 09:38:31 +0100 (IST) Message-ID: <541A9A07.1030103@cs.tcd.ie> Date: Thu, 18 Sep 2014 09:38:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Richard Barnes References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qqtp73BOOBG6ZDDTf4xvhA5Sj2U Cc: Martin Stiemerling , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, IETF SAAG Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 08:39:11 -0000 Hi Richard, On 18/09/14 03:35, Richard Barnes wrote: > As long as we're clear that the way this RFC would help is to avoid > terminology confusion -- not to imply that OS is necessarily the only or > preferred option. Because I don't think there's consensus on the latter. I don't believe that anyone proposed that OS is "the only or preferred option" anywhere at all during the discussion. The lack of consensus for that non-proposal is therefore just fine:-) S. From nobody Thu Sep 18 03:07:26 2014 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 64A171A032A; Thu, 18 Sep 2014 03:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 FjYo-lRWRYkI; Thu, 18 Sep 2014 03:07:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8A1A8719; Thu, 18 Sep 2014 03:07:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9DE10BE83; Thu, 18 Sep 2014 11:07:10 +0100 (IST) 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 kSVQqQPQMyVO; Thu, 18 Sep 2014 11:07:09 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.58.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06D14BDD8; Thu, 18 Sep 2014 11:07:09 +0100 (IST) Message-ID: <541AAECB.6070302@cs.tcd.ie> Date: Thu, 18 Sep 2014 11:07:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Paul Hoffman , Kathleen Moriarty References: <20140915103146.7052.85410.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/DnjNe9oL1mZuxEG85YlkR7Pm424 Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Kathleen Moriarty's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 10:07:15 -0000 Hiya, (Starting to try address IESG comments that can be covered before the call or won't need discussion.) Just to follow up on that, yes I think there'll be a -05 and Viktor can work with Kathleen on incorporating these comments in that. S. On 15/09/14 15:59, Paul Hoffman wrote: > > > Thanks for the comments. Those all seem reasonable and within the > scope of the rough consensus during IETF Last Call. Viktor will > collect these and other IESG comments for a new draft to be posted > after the IESG telechat. > > --Paul Hoffman > From nobody Thu Sep 18 03:29:42 2014 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 80DC21A8745; Thu, 18 Sep 2014 03:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 07s7A70Ebw-l; Thu, 18 Sep 2014 03:29:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 120991A8735; Thu, 18 Sep 2014 03:29:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 03:29:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3YNJW7OgzQ_q7UotDtyZEtZdiWo Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 10:29:38 -0000 Ted Lemon has entered the following ballot position for draft-dukhovni-opportunistic-security-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this document needs to state explicitly that opportunistic security is _not_ appropriate in the same set of applications as mandatory security. E.g., we never want "opportunistic security" when connecting to the bank, or doing a credit card transaction. We want mandatory security. I think that is so obvious to the security folks that nobody thought to mention it, but it must be stated in large friendly letters both in the introduction and in the security considerations section, because this document will be read by non-security-geeks. You should also advise that documents that describe implementations of opportunistic security should mention this in _their_ security considerations section. An opportunistically secure protocol that can be MiTM'd to look secure on the server end whilst being in cleartext on the client end would be disastrous in such contexts. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Aside from issues of accuracy, the choice of the phrase "opportunistic security" is unfortunate because it leads to abbreviation as "OS" which is a well known acronym for "operating system," and a slightly less frequently used acronym for "open source." I'm not raising this as a strong objection, because I know this topic was hotly debated during IETF last call, but the arguments I saw during the debate that it's just not that important and can't be fixed anyway fall flat for me because of this problem. Every time I see "OS support" or something similar in the text, I read "operating system support," not "opportunistic encryption support." If you are going to use this term, I think you should get over the wish for brevity and just spell it out. I would call it "opportunistic protection" or something like that to get a better acronym. Nobody's going to read "OP support" as "original poster support". In section 5: When protection only against passive attacks is negotiated over a channel vulnerable to active downgrade attacks, and the use of encryption fails, a protocol might elect non-intrusive fallback to cleartext. An active attacker could equally have suppressed the use of encryption during negotiation, so failure to encrypt may be more often a symptom of an interoperability problem than an active attack. The last sentence doesn't make sense—the first half of the statement doesn't actually imply the second half as a conclusion, as the "so" in the middle would suggest. It implies the opposite. I don't think you are saying anything wrong here, but you need to clean this text up, because as written it doesn't make sense. When the DISCUSS is cleared, I will change this to a no objection, but while I don't necessarily agree with Barry's remedy for the DISCUSS, I do agree with the general thrust of his DISCUSS. From nobody Thu Sep 18 04:13:09 2014 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 5910E1A8713; Thu, 18 Sep 2014 04:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu_eOpJyVsJH; Thu, 18 Sep 2014 04:12:50 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E3D1A8766; Thu, 18 Sep 2014 04:12:38 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ge10so914931lab.12 for ; Thu, 18 Sep 2014 04:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=bVzC2IEhE5ozZFLx5TjzKomfSU2sqOunE6GuJuJ/nZk=; b=tRjWAqTAtyPsK0PrZuWuUxij/WATf0HY7KZQJopiHAHxDz3bazAztSjBPm/tXjYnL0 xly9kQaZVS7pHIUpyY3kx6CwfsTkG4EAqDGPVQzp1mpth8GM9TT43ZfWvrZnHwUUG5zK uPt/+0MKNxGAorxuTpunzZnwW3cYNwJysvds5mWslVlFf3SpYhKdzU97eZ0ubP8y8koV Wf7FtfPiD5rxvtG0SDtLk8GDaFBWrt45wBQhaN734X7kWm6KbDFoxQ1MA5qlOqLCnu29 ql3ZELZp68SWNCsdgGKPuomEJijIkuY7gHYhs0AQzyVUXnPCZPuS2DI3F2npCOs+MV4b +ACA== X-Received: by 10.152.8.9 with SMTP id n9mr4197663laa.2.1411038756656; Thu, 18 Sep 2014 04:12:36 -0700 (PDT) Received: from [192.168.178.43] (port-92-202-122-51.dynamic.qsc.de. [92.202.122.51]) by mx.google.com with ESMTPSA id xe10sm7037287lbb.37.2014.09.18.04.12.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Sep 2014 04:12:35 -0700 (PDT) References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <54180D8E.6070706@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <85373C4B-BF9A-4431-9EED-C57E9ACBF49F@gmail.com> X-Mailer: iPad Mail (12A365) From: Martin Stiemerling Date: Thu, 18 Sep 2014 13:12:35 +0200 To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_x7FIhdaRfEBlaj9l5R2E_uEC9A Cc: The IESG , "draft-dukhovni-opportunistic-security@tools.ietf.org" , "saag@ietf.org" Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 11:13:02 -0000 Hi Stephen,=20 Thanks for reply.=20 I wonder , if any reference to btns would be useful, sort of historical evid= ence, or not.=20 Thanks, Martin > On 16.09.2014, at 12:14, Stephen Farrell wrote= : >=20 >=20 > Hi Martin, >=20 >> On 16/09/14 10:37, Martin Stiemerling wrote: >> Martin Stiemerling has entered the following ballot position for >> draft-dukhovni-opportunistic-security-04: No Record >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> I am not done with my review, but in the meanwhile I have question:=20 >>=20 >> How does this draft related to the old Better-Than-Nothing Security >> (btns) working group [1] and their output? >=20 > I think its fair to say this LC discussion involved some of the > same protagonists and some of the same arguments. >=20 > Hopefully this RFC would short-circuit a part of the debate > that happened back then (*) but more recently in the httpbis WG. > There was also a bit of that debate in chartering tcpinc. >=20 > The debate that this ought short-circuit is the part about > the overall legitimacy of the approach. So this draft should > save time, energy and good-will when an OS approach is proposed > for other protocols - that part of the discussion seems to me > at least to be contentious, so that can be a non-trivial saving. >=20 > Functionally, I think one could describe the output from BTNS > as following the OS design pattern, but not that successfully. > (The lack of success conclusion being based on the lack of > deployment, it'd probably not be productive to try analyse > the reasons for that further right now - see below.) >=20 > Some of those involved in BTNS have been working on another go > at applying the OS approach to IPsec. That work has not yet > been chartered anywhere but we have had a couple of updates > at saag sessions [2] ([2] btw doesn't use the OS term - it > was done while we were still flailing about with imperfect > term selection;-) If that work got sufficient traction to be > chartered, then this draft should help with that, again by > legitimising the design pattern. The discussion as to why > BTNS wasn't successful, and why some proposed new work might > succeed, would of course still need to be had at chartering > time. >=20 > Hope that covers it, > Cheers, > S. >=20 > [2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf >=20 > (*) I wasn't involved in BTNS really, other than to watch the > fireworks from the sidelines. =46rom that perspective, I think that > history probably explains some of the difficulty getting agreement > with this draft. >=20 >=20 >>=20 >> [1] http://www.ietf.org/wg/concluded/btns.html >>=20 >>=20 From nobody Thu Sep 18 04:27:10 2014 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 0F1B61A872D; Thu, 18 Sep 2014 04:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 JVl1KbbGNtpP; Thu, 18 Sep 2014 04:27:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5132E1A014D; Thu, 18 Sep 2014 04:27:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6AF5FBE80; Thu, 18 Sep 2014 12:27:05 +0100 (IST) 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 Gb7QsEwIRnkM; Thu, 18 Sep 2014 12:27:03 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.58.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04092BDFE; Thu, 18 Sep 2014 12:27:03 +0100 (IST) Message-ID: <541AC186.1090500@cs.tcd.ie> Date: Thu, 18 Sep 2014 12:27:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Martin Stiemerling References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> <85373C4B-BF9A-4431-9EED-C57E9ACBF49F@gmail.com> In-Reply-To: <85373C4B-BF9A-4431-9EED-C57E9ACBF49F@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/byEhnaIhMtawAxayljQ0jGTSbHo Cc: "saag@ietf.org" , The IESG , "draft-dukhovni-opportunistic-security@tools.ietf.org" Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 11:27:09 -0000 On 18/09/14 12:12, Martin Stiemerling wrote: > Hi Stephen, > > Thanks for reply. > > I wonder , if any reference to btns would be useful, sort of historical evidence, or not. Mostly "not" I think:-) One of the reasons we ended up with Viktor's draft was (I think) that folks were somewhat worried that a bunch of the historic text in Steve Kent's draft [1] would bog us down in debate/recriminations/whatever. The stuff Viktor added about starttls [2] is I think enough of, and a better, demonstration that OS can be useful. And we don't need to try enumerate all past cases of OS either. So on balance I'd argue for not adding such. Cheers, S. PS: That said, I do think that the historic text in Steve's draft would be useful to publish too somehow. I'm less sure I'd like another LC on this topic soon though;-) [1] https://tools.ietf.org/html/draft-kent-opportunistic-security [2] https://tools.ietf.org/html/draft-dukhovni-opportunistic-security-04#section-4 > > Thanks, > > Martin > > > >> On 16.09.2014, at 12:14, Stephen Farrell wrote: >> >> >> Hi Martin, >> >>> On 16/09/14 10:37, Martin Stiemerling wrote: >>> Martin Stiemerling has entered the following ballot position for >>> draft-dukhovni-opportunistic-security-04: No Record >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> I am not done with my review, but in the meanwhile I have question: >>> >>> How does this draft related to the old Better-Than-Nothing Security >>> (btns) working group [1] and their output? >> >> I think its fair to say this LC discussion involved some of the >> same protagonists and some of the same arguments. >> >> Hopefully this RFC would short-circuit a part of the debate >> that happened back then (*) but more recently in the httpbis WG. >> There was also a bit of that debate in chartering tcpinc. >> >> The debate that this ought short-circuit is the part about >> the overall legitimacy of the approach. So this draft should >> save time, energy and good-will when an OS approach is proposed >> for other protocols - that part of the discussion seems to me >> at least to be contentious, so that can be a non-trivial saving. >> >> Functionally, I think one could describe the output from BTNS >> as following the OS design pattern, but not that successfully. >> (The lack of success conclusion being based on the lack of >> deployment, it'd probably not be productive to try analyse >> the reasons for that further right now - see below.) >> >> Some of those involved in BTNS have been working on another go >> at applying the OS approach to IPsec. That work has not yet >> been chartered anywhere but we have had a couple of updates >> at saag sessions [2] ([2] btw doesn't use the OS term - it >> was done while we were still flailing about with imperfect >> term selection;-) If that work got sufficient traction to be >> chartered, then this draft should help with that, again by >> legitimising the design pattern. The discussion as to why >> BTNS wasn't successful, and why some proposed new work might >> succeed, would of course still need to be had at chartering >> time. >> >> Hope that covers it, >> Cheers, >> S. >> >> [2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf >> >> (*) I wasn't involved in BTNS really, other than to watch the >> fireworks from the sidelines. From that perspective, I think that >> history probably explains some of the difficulty getting agreement >> with this draft. >> >> >>> >>> [1] http://www.ietf.org/wg/concluded/btns.html >>> >>> > From nobody Thu Sep 18 05:58:16 2014 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 1BCB51A038C; Thu, 18 Sep 2014 05:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 wtmzzFcnWGHp; Thu, 18 Sep 2014 05:58:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 636481A00F5; Thu, 18 Sep 2014 05:58:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918125812.26793.78875.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 05:58:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pGHG2hpx_eKoi1UFwR_rTow3U54 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Pete Resnick's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 12:58:14 -0000 Pete Resnick has entered the following ballot position for draft-dukhovni-opportunistic-security-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I had a full-out rant prepared about "tracking of issues" and such, but a night's sleep is a good thing. I've decided things are much simpler than that: There were substantive non-editorial changes between -03 and -04, substantive changes that *I* think have damaged the document in a substantive way, and changes about which the community does not have consensus. I believe there are things that need fixing, and therefore discussing. (For those playing at home, I'm hanging my hat on the last bullet of http://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc for this.) Let's start with the Intro: Broadly speaking, Opportunistic Security (OS) is a pragmatic risk management approach. With Opportunistic Security, one applies the tools at hand to mitigate the risks that can reasonably be addressed, and accepts the rest. This is new text, not an editorial change. I find both of those sentences, and most of the other sentences in the Introduction, completely useless to the task of explaining what is important about OS, and unfortunately I think the Introduction as a whole now makes it *harder* for the reader to understand what OS is. I don't think there is community consensus that the new intro captures the intent. Most importantly: Thus, use of an OS protocol may yield communication that is authenticated and encrypted, unauthenticated but encrypted, or cleartext. I find completely insidious because it damages the message of 1.2: Instead of a build up from a base of cleartext, which I absolutely agree is the way we should be thinking about security and is the essential bit of the OS model, this sentence and the one that follows it reinforce the notion that we start from fully authenticated communication and work our way down, precisely the notion that this document is supposed to be moving us away from. The definition presented in this section also hides this important point. The two essential bits of intro are the first paragraph of section 1.1 (which was once the first paragraph of the document) and the first two paragraphs of section 1.2, and we don't get to read them for another 6 to 15 paragraphs. They need to be moved up and the rest of this new intro needs to be deleted. In section 3: Coexist with local policy: Local security policies preempt OS. Opportunistic security never displaces or preempts local policy. Many applications and types of data are too sensitive to use OS, and more traditional security designs are appropriate in such cases. The title of section 3 is "Opportunistic Security Design Principles". Coexisting with local policy is not part of the OS design principle; it's a caveat to that design principle for times when you should *not* use OS. Again, this undermines the discussion of OS, and I do not believe that the community has consensus that the above is part of the OS design principle. (One overarching point: Others have made comments with other serious problems that need fixing. That's fine. But if the result of addressing my comments or other folks's comments is to *add* more text, you've probably gotten it wrong. The main problem with -04 is the text that it added. Text needs to be deleted and simplified.) This is important work and really needs to be done. In retrospect, I would have preferred to see this work done as a BCP in UTA or as an IAB document instead of simply a definition document. But we are where we are. We need to come to consensus on the text in here. We're not there yet. From nobody Thu Sep 18 06:17:17 2014 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 253A31A8789; Thu, 18 Sep 2014 06:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0YQmDcqqVcSp; Thu, 18 Sep 2014 06:17:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDBC1A00F5; Thu, 18 Sep 2014 06:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918131713.27852.67227.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 06:17:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/SIfyxNVUX1Sj4LUb9Cb_lC01jz8 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Brian Haberman's No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:17:16 -0000 Brian Haberman has entered the following ballot position for draft-dukhovni-opportunistic-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I did not have the time to dig through all of the IETF Last Call comments, so I am observing the process DISCUSSion with interest. I do support the clarity issues raised by Adrian, Alissa, and Pete. From nobody Thu Sep 18 06:48:56 2014 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 E1FBB1A87D0; Thu, 18 Sep 2014 06:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.653 X-Spam-Level: X-Spam-Status: No, score=-8.653 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=-1.652, 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 HKEdaO66qxAH; Thu, 18 Sep 2014 06:48:49 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EECE1A0346; Thu, 18 Sep 2014 06:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411048129; x=1442584129; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LRHqcQafNg5WZ53BFQs3Q/fTdk5w5w5DnR6FrfxJAho=; b=b9tkuHRZgE2qdZJEU8sRAqf/EfRo1Dk7Qqji61W7/PzFKx/txU6xX5LE WsSjWM8Y7JrK7DLq77yWJ1jH1eOp0/gP6xAGLJDW6/NGm3QZBmliNAKeF +hmjuVHcTlaseWYZs3XzUP7oTpIxzjoba0yX9pDwVJHRxbeLGTcEeQ23W Y=; X-IronPort-AV: E=McAfee;i="5600,1067,7564"; a="159616967" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Sep 2014 06:48:48 -0700 X-IronPort-AV: E=Sophos;i="5.04,547,1406617200"; d="scan'208";a="807658771" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Sep 2014 06:48:49 -0700 Received: from nasanexm01a.na.qualcomm.com (129.46.53.228) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 18 Sep 2014 06:48:47 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by nasanexm01a.na.qualcomm.com (129.46.53.228) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 18 Sep 2014 06:48:47 -0700 Message-ID: <541AE2BD.6050900@qti.qualcomm.com> Date: Thu, 18 Sep 2014 08:48:45 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: The IESG References: <20140918125812.26793.78875.idtracker@ietfa.amsl.com> In-Reply-To: <20140918125812.26793.78875.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To nasanexm01a.na.qualcomm.com (129.46.53.228) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Z7JOA58HAGMEl3pBnedb-52foyA Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Pete Resnick's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS) 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, 18 Sep 2014 13:48:51 -0000 I added a bit to my ballot due to conversations with Stephen, but I don't want to re-send a whole new ballot. I just changed this: On 9/18/14 7:58 AM, Pete Resnick wrote: > Instead of a build up from a base of cleartext, which I absolutely agree > is the way we should be thinking about security and is the essential bit > of the OS model, this sentence and the one that follows it reinforce the > notion that we start from fully authenticated communication and work our > way down, precisely the notion that this document is supposed to be > moving us away from. > I added: -03 made it clear to me that there was an order to things. It said that there was "stepping up from" cleartext. That text disappeared. In its place, there is the above text that apparently has the steps in the reverse order. The definition of the term in -04 doesn't even refer to the order. I do not remember seeing any discussion in which the participants came to consensus that this discussion of order should be removed. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Sep 18 07:37:28 2014 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 F20171A8832 for ; Thu, 18 Sep 2014 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 R15WHp6FQyqw for ; Thu, 18 Sep 2014 07:37:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 54F1F1A8831 for ; Thu, 18 Sep 2014 07:37:24 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8IEP3vq006989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 18 Sep 2014 10:25:04 -0400 Received: from bofh.nohats.ca (vpn-61-17.rdu2.redhat.com [10.10.61.17]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8IEP3Pj007753 for ; Thu, 18 Sep 2014 10:25:03 -0400 Message-ID: <541AEB3F.3020006@redhat.com> Date: Thu, 18 Sep 2014 10:25:03 -0400 From: Paul Wouters User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> In-Reply-To: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/bnrZkquHVsf7nRMWD6wDsV9_j80 Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 14:37:26 -0000 On 09/18/2014 06:29 AM, Ted Lemon wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I think this document needs to state explicitly that opportunistic > security is _not_ appropriate in the same set of applications as > mandatory security. E.g., we never want "opportunistic security" when > connecting to the bank, or doing a credit card transaction. That really comes down to your definition of "application". For example, in an IKE daemon for IPsec, you would be handling both user defined VPN tunnels (to your bank, your home, your work) as well as OS based tunnels (to hosts you don't have a preconfigured security relationship with). I think your definition of application would not include the IKE daemon? But even within an application (browser, mail client, IM client) one could have multiple configurations. I could have IM application which talks using DANE secured TLS for one XMPP account (eg work), but using OS based security for some public IRC server. What you really mean to say, which the document does say but perhaps not explicitly enough, is that OS MUST NEVER trump preconfigured authenticated encryption, and MUST only be attempted if not doing OS would result in communication in cleartext. Paul From nobody Thu Sep 18 07:42:39 2014 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 566F01A87F1; Thu, 18 Sep 2014 07:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 BrLK5hlUYASb; Thu, 18 Sep 2014 07:42:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 29AAF1A040E; Thu, 18 Sep 2014 07:42:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C9FA6BE83; Thu, 18 Sep 2014 15:42:26 +0100 (IST) 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 tIvPUs4jEF6J; Thu, 18 Sep 2014 15:42:20 +0100 (IST) Received: from [10.87.48.5] (unknown [86.41.58.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5953BBE01; Thu, 18 Sep 2014 15:42:20 +0100 (IST) Message-ID: <541AEF4C.6010107@cs.tcd.ie> Date: Thu, 18 Sep 2014 15:42:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Adrian Farrel , The IESG References: <20140915171334.989.63043.idtracker@ietfa.amsl.com> In-Reply-To: <20140915171334.989.63043.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/-Mgc7ZPnYofXsK3XIoCgdSzdTUo Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Adrian Farrel's Abstain on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 14:42:37 -0000 Hi Adrian, More detailed initial responses below. (From Viktor as marked). On 15/09/14 18:13, Adrian Farrel wrote: > - - - - > > Abstract... > > Protocol designs based on > Opportunistic Security remove barriers to the widespread use of > encryption on the Internet by using encryption even when > authentication is not available > > So, this says "remove barriers to X by using X". More: "remove barriers to X using *X even without Y*" > I think there is probably something additional you need to say before > this sentence. For example, "Most approaches to the use of encryption > on the Internet depend on the use authentication to foo. This makes > encryption unattractive because bar." Not sure if we really need it in the abstract as its in the body I think. (It does need saying, just not sure if twice.) > > --- > > Introduction > > Broadly speaking, Opportunistic Security (OS) is a pragmatic risk > management approach. > > "pragmatic" is redundant in the description of "risk management". Disagree. Insisting on mutual authentication of all sessions is (historically) considered a valid approach to risk management (by us:-) but is less pragmatic than OS. > > "...approach" to what? I think the phrasing is clear. Is that just a wording preference or do you think its really not clear? > > --- > > Introduction > > With Opportunistic Security, one applies the > tools at hand > > This implies to me that no changes or modifications to protocols are > needed to achieve OS. I don't believe that is true. TLS is a tool. Modifying how TLS is used with HTTP to follow the OS pattern as is being considered by httpbis does involve using the tools at hand and also involves change. So I don't get how you draw that implication tbh. You are correct of course that changes are needed when following the OS pattern. > > --- > > The definition presented in Section 1 is OK as far as it goes, but > isn't it missing also the existence of the capability in the protocol > itself? Not sure what that means if its not what's in the next para. > > Isn't a fundamental part of OS that the operation of encryption can be > without manual keying and therefore without the configuration of > security adjacencies? I think that what is missing from this document, > and possibly from this definition, is a description of why security > (specifically encryption) is not widely used in the Internet today. Hmm. Sorta. I'm not sure fundamental is correct, nor that we need to identify and describe all the fundamental parts of OS, nor decide exactly what is fundamental and what is not. The draft already does say that we lack an Internet-scale key management scheme, which is the point you're making I think. I'm not sure it'd be a good idea to call out one aspect of that as you've done above since there are others arguably equally fundamental (what authorities to use, how to revoke bindings, how to discover capabilities and keys etc.). > > It is also a little questionable to me what is "opportunistic" in this > definition. You seem to be defining "Best Effort Security". Hey-ho. It's > only a name, and just words. I don't think we'll benefit from talking other terms. > > --- > > Introduction > > Since encryption alone mitigates only > passive attacks, this risk is consistent with the expected level of > protection. > > "Since encryption alone..." can be read two ways: > 1. Only encryption can do this > 2. Using only encryption with nothing else can only go so far > I suggest you make some clarification to remove this ambiguity. Ack. #2 is clearly what's meant but sure. > > "this risk is consistent with the expected..." I don't think so. I think > the risk defines the level of protection that can be delivered. Not in the usual sense in which the term risk is used in security, no. > Expectations need to be set and this document can do so by describing > the risks and the likelihoods. I don't know what you mean there sorry. (Maybe due to the above for me odd use of the word risk.) > > --- > > For authentication based on peer capabilities to protect > against MiTM attacks, capability advertisements need to be over an > out-of-band authenticated channel that is itself resistant to MiTM > attack. > > I had a lot of trouble parsing the first clause in this sentence. Is it > the peer capabilities that can protect against MiTM attacks? Or is it > the authentication that does the protection? I think you are saying... > In order that authentication mechanisms can protect against active > MiTM attacks on capability exchanges between peers, those capability > exchanges need to be performed over... > > But why are you insistent on an out-of-band channel? Surely any > authenticated channel that is resistant to MiTM attacks will be good > enough? Viktor said: Neither of the above alternatives are it. "authentication based on peer capabilities" is intended to be read as a single long compound noun. The intended meaning is then: When authentication is used only if advertised by the peer, protection against MiTM attacks requires that the advertisement be over an out-of-band authenticated channel ... Because active attacks on the the advertisement can otherwise strip or modify the authentication capability data and then compromise the communication with the peer. > > --- > > OS protocols will attempt to establish encrypted communication > whenever both parties are capable of such, and authenticated > communication if that is also possible. This last outcome will > occur if not all parties to a communication support encryption (or if > an active attack makes it appear that this is the case). > > Is there any element of choice here? The text says not. You take "will attempt" as the same as MUST? I don't think that is the intent. Maybe s/will attempt/attempt/ would work? > > --- > > For a particular protocol or application, if and when all but a > negligible fraction of peers support encryption, the baseline > security may be raised from cleartext to always require encryption. > Similarly, once support for authentication is near-universal, the > baseline may be raised to always require authentication. > > I don't know what this means! > I think it says that at some moment in time the Internet Police will > ban the use of unencrypted use of a protocol or application. Or maybe > it says that new implementations can require encryption and refuse to > operate with legacy implementations. Or perhaps you mean that the > default behaviour should be to try for encryption. Or perhaps you are > just talking about what the user can expect. Viktor says: RFCs updating the protocol may then specify that implementations should not support cleartext, and correspondingly updated implementations will then refuse to communicate in cleartext (based on presumptively near-universal support for encryption even among legacy peers). > > --- > > The abbreviation "CA" is used without expansion. Ack. > > --- > > Section 1.1 > > DNSSEC is not > sufficiently widely deployed to allow DANE to satisfy the Internet- > wide, any-to-any authentication requirement noted above. > > Did I miss the any-to-any requirement? I looked back but didn't find it. Its arguably implicit in an Internet scale key management scheme, but could be made expicit or this re-worded yes. > > --- > > Section 1.1 makes a good case about encryption without authentication > being of value. But this seems to be making a different (although > equally valid) case from the basis of the document that is about OS. > This comes back to the "opportunistic" versus "best effort" thing. I'm not getting the import of that comment. > > --- > > Section 1.1 > > The use of encryption defends against pervasive monitoring > and other passive attacks (which are employed not only by nation > states). > > The parenthesised text can probably be dropped. It is not a discussion > you need to have here. True. OTOH, its no hard. (I can't recall it it was added because of some earlier comment.) > > --- > > Section 1.1 > > For some applications or protocols the set of potential peers > includes a long tail of implementations that support only cleartext. > > On third reading I got what the "long tail" refers to. How about... > > For some applications or protocols it is anticipated that the set of > potential peers that only support cleartext will persist for a long > time. Sure, that'd be fine. > > --- > > Section 1.2 > > This document proposes a change of perspective. > > Why is it a proposal in what you plan to publish as an IETF Consensus > RFC? I assume you don't really want this to be Experimental. I think the text is clear there. > > --- > > I am fine with the concept of opportunistic security and like it. But > I think I reject the hypothesis in Section 1.2 that the old world is > "expect full security and notify when not achieved" and that the new > world is "expect no security and get the best you can." I think the new > world is / should be "configure the level of security that is acceptable > to you, get at least that security and maybe better, or get notified if > it is not as good." This is more subtle than your proposal but involves > the user in a way that I think is important. That is, if a user desires > security, it is not enough to say "the protocol is designed to get as > much security as it can" - the user actually wants to know if the > security level is low, and may want no traffic if the security level is > too low. > > This does not reject the idea of OS, but merely the choice presented in > Section 1.2. > > In fact, Section 3 makes these trade-offs pretty clear, so I think > that all that is needed is to moderate the language in this section. > (Although Section 5 seems to favour some sort of autonomy within the > protocol or protocol implementation such that various fallbacks might > "just happen".) I'm not clear what you mean by moderate. And we definitely don't want to say "user" too often or in the wrong places (that and UI issues have been discussed a lot already). So I'm not sure what changes here might help. > > --- > > Section 3 > > OS provides a near-term approach to counter passive attacks by > removing barriers to the widespread use of encryption. > > This is probably true, and definitely a motivation, and not a Design > Principle. Not appropriate in this section of the document. I disagree. But am maybe less concerned at Design Principle being strictly interpreted. But I agree that the 1st 2 sentences in section 3 could be moved elsewhere. > > --- > > Section 3 > > I had to read "Emphasize enabling communication" and the following text > a couple of time to extract the right meaning. What you have has two > different meanings, and you mean "enablement of" (otherwise "an > enabling communication" is inferred). Ack. > > --- > > Section 5 has... > > The choice > to implement or enable fallback should only be made in response to > significant operational obstacles. > > ...but no mention of who makes the choice for enablement. I think you > need that such fallback is never a default action and always requires > operator/user intervention since forcing such a fallback sounds like an > effective attack. Viktor says: It is difficult to be prescriptive here. With SMTP, fallback from STARTTLS (after handshake failure) to cleartext is often automatic (default MTA behaviour). It is not expected that defenses against passive attacks are immune to active attack. However it may be reasonable to give users/operators the choice to override default behaviour by enabling or disabling fallback as appropriate. Stephen says: I thought the "who" was clear given the section title, but it'd be fine to clarify that I think. I'm less sure one can confidently say that such fallback is "never a default" as there might be cases where some algorithm would be fine. > --- > > One point that I would possibly have entered as a Discuss were I not > Abstaining is that I am surprised that there is no discussion of > mechanisms that can be used to detect MiTM attacks on unauthenticated > encryption key exchanges. Detection is a useful tool since, while it > can't help with protection of data, it can at least warn the user to > stop relying on the security of the data channel. Viktor says: Specific recommendations are difficult. I think that any such mechanisms will be significantly protocol/application specific. One might encourage protocol designers to consider the issue. OS will be primarily used where nothing better than cleartext is expected, and warnings of MiTM attacks on unauthenticated encryption may be counter-productive if more often than not the cause is routine key rotation by the peer. Stephen says: I think some text there would be good, but we should be cautious to not say that e.g. just because D-H is used, one can easily catch a MitM post-facto. (In the general case there are tricky issues with that.) But there will be cases where some later OOB communications could post-facto catch an otherwise successful MitM attack. Cheers, S. > > From nobody Thu Sep 18 07:43:51 2014 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 609641A883A; Thu, 18 Sep 2014 07:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9SP5xyHVE5S; Thu, 18 Sep 2014 07:43:32 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED83F1A8821; Thu, 18 Sep 2014 07:43:31 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id q1so1285177lam.31 for ; Thu, 18 Sep 2014 07:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OUZilV0sYfLsmT016aQvmTaYnFKh6eayuH1P7zibkb4=; b=kDdiMn8+ZUkGlGKMiJwDcYNWXGFLkmONkkLMIpuLZnB7Fa2lI939O4lAmeVNiv3DSB RDBv7ExCNKlkkKevfrnk9ycRJ2bdBViL2FjF8ZiFjyW13RLGL5skeGVPTBVdjnrQXZe9 +TdDK22sZYMLO/id7n7Efd7POUq7GRhKuhBLyjBcH7KtJq2gL1qG8qRj/kQQyynt7mso iAEA9ngJO6QMvgeGbHumPTLGVs6KIyB5ZlACn9alzhIBnVzI2QR/ND1pnhnO85UYrVZ0 k2lHNrfb0iiOUFDaqtjs8Y4Ly9GwwzRdIR9z9ANfwEGPJ3WNHI33JnRKCv26g/VGvyCd 2WRA== X-Received: by 10.112.13.232 with SMTP id k8mr20162lbc.81.1411051410230; Thu, 18 Sep 2014 07:43:30 -0700 (PDT) Received: from martins-mbp-4.fritz.box ([2001:1a80:2805:f000:88a2:ce42:474a:822f]) by mx.google.com with ESMTPSA id q14sm3269985lal.6.2014.09.18.07.43.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Sep 2014 07:43:29 -0700 (PDT) Message-ID: <541AEF8C.60704@gmail.com> Date: Thu, 18 Sep 2014 16:43:24 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Stephen Farrell References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> <85373C4B-BF9A-4431-9EED-C57E9ACBF49F@gmail.com> <541AC186.1090500@cs.tcd.ie> In-Reply-To: <541AC186.1090500@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/_TdlidUOoNCCOjazlKx7th5qYFc Cc: "saag@ietf.org" , The IESG , "draft-dukhovni-opportunistic-security@tools.ietf.org" Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 14:43:38 -0000 Am 18.09.14 um 13:27 schrieb Stephen Farrell: > > > On 18/09/14 12:12, Martin Stiemerling wrote: >> Hi Stephen, >> >> Thanks for reply. >> >> I wonder , if any reference to btns would be useful, sort of historical evidence, or not. > > Mostly "not" I think:-) One of the reasons we ended up with > Viktor's draft was (I think) that folks were somewhat worried > that a bunch of the historic text in Steve Kent's draft [1] > would bog us down in debate/recriminations/whatever. > > The stuff Viktor added about starttls [2] is I think enough > of, and a better, demonstration that OS can be useful. And > we don't need to try enumerate all past cases of OS either. > So on balance I'd argue for not adding such. wfm. > > Cheers, > S. > > PS: That said, I do think that the historic text in Steve's > draft would be useful to publish too somehow. I'm less sure > I'd like another LC on this topic soon though;-) :) > > [1] https://tools.ietf.org/html/draft-kent-opportunistic-security > [2] > https://tools.ietf.org/html/draft-dukhovni-opportunistic-security-04#section-4 > > >> >> Thanks, >> >> Martin >> >> >> >>> On 16.09.2014, at 12:14, Stephen Farrell wrote: >>> >>> >>> Hi Martin, >>> >>>> On 16/09/14 10:37, Martin Stiemerling wrote: >>>> Martin Stiemerling has entered the following ballot position for >>>> draft-dukhovni-opportunistic-security-04: No Record >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I am not done with my review, but in the meanwhile I have question: >>>> >>>> How does this draft related to the old Better-Than-Nothing Security >>>> (btns) working group [1] and their output? >>> >>> I think its fair to say this LC discussion involved some of the >>> same protagonists and some of the same arguments. >>> >>> Hopefully this RFC would short-circuit a part of the debate >>> that happened back then (*) but more recently in the httpbis WG. >>> There was also a bit of that debate in chartering tcpinc. >>> >>> The debate that this ought short-circuit is the part about >>> the overall legitimacy of the approach. So this draft should >>> save time, energy and good-will when an OS approach is proposed >>> for other protocols - that part of the discussion seems to me >>> at least to be contentious, so that can be a non-trivial saving. >>> >>> Functionally, I think one could describe the output from BTNS >>> as following the OS design pattern, but not that successfully. >>> (The lack of success conclusion being based on the lack of >>> deployment, it'd probably not be productive to try analyse >>> the reasons for that further right now - see below.) >>> >>> Some of those involved in BTNS have been working on another go >>> at applying the OS approach to IPsec. That work has not yet >>> been chartered anywhere but we have had a couple of updates >>> at saag sessions [2] ([2] btw doesn't use the OS term - it >>> was done while we were still flailing about with imperfect >>> term selection;-) If that work got sufficient traction to be >>> chartered, then this draft should help with that, again by >>> legitimising the design pattern. The discussion as to why >>> BTNS wasn't successful, and why some proposed new work might >>> succeed, would of course still need to be had at chartering >>> time. >>> >>> Hope that covers it, >>> Cheers, >>> S. >>> >>> [2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf >>> >>> (*) I wasn't involved in BTNS really, other than to watch the >>> fireworks from the sidelines. From that perspective, I think that >>> history probably explains some of the difficulty getting agreement >>> with this draft. >>> >>> >>>> >>>> [1] http://www.ietf.org/wg/concluded/btns.html >>>> >>>> >> From nobody Thu Sep 18 08:01:16 2014 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 B67471A6F33; Wed, 17 Sep 2014 14:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 IYLuWlKqqSO0; Wed, 17 Sep 2014 14:18:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 049021A6F27; Wed, 17 Sep 2014 14:18:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> Date: Wed, 17 Sep 2014 14:18:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/hjbfBrv_XMZGShrRLpgBqAYasAw X-Mailman-Approved-At: Thu, 18 Sep 2014 08:01:13 -0700 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 21:18:52 -0000 Alia Atlas has entered the following ballot position for draft-dukhovni-opportunistic-security-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First, I am quite supportive of a revision of this document going forward. It provides a pragmatic and useful mindset towards mitigating pervasive monitoring. However, I do support Barry's Discuss. I have not followed all of the discussion on the IETF list about the draft, but enough to feel uncomfortable about the interactions. There can certainly be rough consensus but the reaction seems to be more about transparency of what and why things were changes. Secondly, I am not fond of the term "Opportunistic Security" as compared to "Opportunistic Encryption" if encryption is really all that is meant. For instance, does OS have the ability to improve over clear-text to prevent replay attacks? That's something that encryption alone doesn't necessarily provide; of course, it can also be protocol-specific. IF this is about OS and not OE, I would find it useful to be clearer about the dimensions/aspects of security that can be opportunistic. It definitely reads like this is only about opportunistic encryption and nothing else. From nobody Thu Sep 18 09:10:28 2014 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 1C38B1A8874 for ; Thu, 18 Sep 2014 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nHYwqeOqsV4C for ; Thu, 18 Sep 2014 09:09:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A471A045E for ; Thu, 18 Sep 2014 09:09:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CD68C2AAC74; Thu, 18 Sep 2014 16:09:50 +0000 (UTC) Date: Thu, 18 Sep 2014 16:09:50 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140918160950.GJ26920@mournblade.imrryr.org> References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> <541AEB3F.3020006@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541AEB3F.3020006@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BwuLhOlRINS2oLdz-guDImHeil0 Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 16:10:17 -0000 On Thu, Sep 18, 2014 at 10:25:03AM -0400, Paul Wouters wrote: > What you really mean to say, which the document does say but perhaps not > explicitly enough, is that OS MUST NEVER trump preconfigured authenticated > encryption, and MUST only be attempted if not doing OS would result in > communication in cleartext. Indeed, but somewhat generally: Basically, OS can raise "the floor" (baseline security policy) but never lower it. If local policy or the protocol specification sets the floor to "unauthenticated, encrypted communication" then OS might potentially raise that to authenticated, encrypted communication with some peers. If, as Paul explains, the floor is cleartext, then OS can exceed that. If the floor and ceiling (most you could get) coincide then there's no room for OS. Local policy can of course set either the ceiling or the floor, possibly to the same value, or leave a gap in which OS can operate. Things like the use of "https" vs "http" URIs are one way of expressing local policy. -- Viktor. From nobody Thu Sep 18 09:13:33 2014 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 9BF9A1A045E; Thu, 18 Sep 2014 09:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jmQQTln-AREY; Thu, 18 Sep 2014 09:13:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF761A0460; Thu, 18 Sep 2014 09:13:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A82B12AAC74; Thu, 18 Sep 2014 16:13:25 +0000 (UTC) Date: Thu, 18 Sep 2014 16:13:25 +0000 From: Viktor Dukhovni To: The IESG , saag@ietf.org Message-ID: <20140918161325.GK26920@mournblade.imrryr.org> References: <20140917180633.7822.23633.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140917180633.7822.23633.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/thPiiLhh6XIAWhZ4dm8AJIsH5ek Subject: Re: [saag] Alissa Cooper's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 16:13:29 -0000 On Wed, Sep 17, 2014 at 11:06:33 -0700, Alissa Cooper wrote: > DISCUSS: > > o Section 1: > "For a particular protocol or application, if and when all but a > negligible fraction of peers support encryption, the baseline > security may be raised from cleartext to always require encryption. > Similarly, once support for authentication is near-universal, the > baseline may be raised to always require authentication." > > I agree with Adrian that it is unclear what this means. And in fact it > seems to contradict other language in the document by assuming that a > protocol has one mode of operation for *all* peers. I thought one of the > goals of OS was that within any single protocol interaction or within any > single group of peers, the level of encryption used could be negotiated > up to the lowest common denominator among the peers. Perhaps this would > be clearer if it emphasized that the default mode for a particular > protocol or application might be chosen to be cleartext, unauthenticated > encryption, or authenticated encryption, with the ability for peers to > negotiate up if they are capable. The language is about protocol designs, and the specified baseline for a given protocol. The intent is to allow future revisions of say SMTP to specify unauthenticated TLS as a baseline requirement (obviously subject to local policy that might relax to cleartext in some deployments or with some peers). Naturally, such decisions may also be made by operators. If this is done in the context of near universal adoption of STARTTLS, then the default behaviour of updated or suitably configured SMTP clients will be to require STARTTLS. Their opportunistic behaviour then boils down to using or not using DANE TLS authentication based on the peer's TLSA RRs or their absence. I don't see the contradiction part. This language allows a (future) lowest common denominator other than cleartext for protocols that have achieved spectacular adoption of encryption, and are ready to declare victory on that. > o Section 1: > "In essence, OS is employed when one might otherwise settle for > cleartext (or the minimum protection possible if the protocol > is always encrypted)." > > I don't understand the parenthetical, either in substance or grammar. The parenthetical is therefore for hypothetical future cases in which the baseline has been raised. > o Section 1: > "For example, a policy might require authenticated, encrypted > communication, in contrast to the default OS security policy." > > This sentence presents another reason why the previous paragraph does not > make sense. The previous paragraph seems to say that in some cases, the > default OS security policy could be to use authenticated encryption. In > those cases, this sentence is not correct. I see no conflict here, the sentence gives an example in which local policy might be different from the default OS policy, hence presumptively when the default policy is in fact different from authenticated, encrypted communication. > o Section 1.2: > > I find the document's guidance about the extent to which OS protocols > "work behind the scenes" to be confusing. There is this text in this > section: OS is supposed to something non-intrusive that is on by default, and needs to rarely fail in practice (absent an actual attack). > "OS protocols work > transparently behind the scenes, without disrupting communication. > > When less than complete protection is negotiated, there is no need to > prompt the user with "your security may be degraded, please click OK" > dialogs. The negotiated protection is as good as can be expected. > Even if not comprehensive, it is often better than the traditional > outcome of either "no protection" or "communications failure"." > > And then in Section 3 there is this: > > "No misrepresentation of security: Unauthenticated, encrypted > communication must not be misrepresented to users or in > application logs of non-interactive applications as equivalent to > authenticated, encrypted communication." > > The bit about working "behind the scenes" and not prompting the user > seems to me to be distinct from the issue of misrepresenting security. They are, as you observe, in fact different. One is about not being fragile or intrusive, the other is about not over-representing the security achieved, if any. In the former we're discouraging failure modes and warning dialogs, in the latter we're discouraging misleading security indicators. > That is, (1) whether the user is pro-actively informed of the extent to > which his communications are protected, (2) whether the user is able to > find out about that protection on his own, and (3) whether the > information provided to the user about that protection is accurate are > three separate questions. I find that Section 1.2 argues against (1), The draft argues against misrepresentation, this is not the same as suppression of information. So there is no argument against (1) in 1.2 or in 3. > principle. I believe the document is silent about (2). Indeed the document is strategically silent about user interfaces. > I get the sense that (1) is viewed by people who worked on this document > as an important by-product of wider deployment of OS, so I would have > expected support for it to be more explicit in the document, rather than > somewhat latent as it is. I think of it in the converse. Non-intrusive designs make wider deployment more likely, by not getting in the way of communication. The corollary is that OS designs should be non-intrusive, especially because they're typically intended to be transparent upgrades from no security. > If there were a fuller discussion of (1), I > would also expect (2) to be addressed, as it is natural to ask just how > "behind the scenes" OS protocols are expected to be (as Adrian pointed > out). This seems like a fairly significant gap in the document. Many comments wanted a shorter document. I am willing to write more, but tried to strike a balance between outlining the principles as briefly as possible and detailed exposition. > o Section 1: > s/For authentication based on peer capabilities to protect > against MiTM attacks/For authentication based on peer capabilities to > be able to protect against MiTM attacks/ > > (FWIW, the above makes more sense to me than Adrian's suggested edit to > the same sentence.) Yes, this matches the intent and I think addresses Adrian's concerns with the same text. > o Section 1.1: > General comment: It is really unclear what the point of this section is > and why this set of paragraphs is strung together as one section. I would > suggest adding an opening paragraph along the lines of "This section > provides some background about historic and current challenges associated > with the use of encryption on the Internet, illustrated using discussion > of the Web PKI." This section explains why we don't yet have ubiquitous authenticated encryption, and why therefore authentication needs to be optional. An opening sentence or paragraph can be added to say so. > o Section 1.1: > s/With so many certification authorities, which not everyone is willing > to trust, the communicating parties don't always agree on a mutually > trusted CA./With so many certification authorities, all of which are > not trusted by all entities, the communicating parties don't always > agree on a mutually trusted CA./ The suggested text is not IMHO better, but we can try to make the original more clear. (To me "all of which are not trusted by all" means none are trusted by any). > o Section 1.1: > > "In interactive > applications, security warnings are all too frequent, and end-users > learn to actively ignore security problems" This is text from Paul Wouters, ... I think it is a fair point. When security expectations exceed reality, one gets various kinds of friction. > This point is orthogonal to the rest of the paragraph to which it is > attached. The fact that choices were made to pop security warnings was > separate from other choices made about the web PKI. It doesn't quite make > sense to me why this is mushed together with a paragraph about "cost and > management burdens." One of the costs is habituating users to work-around security. However, this point is not essential and could be merged into Security Considerations or dropped if that's better.. > o Section 1.1: > > "For encryption to be used more broadly, authentication needs to be > optional. The use of encryption defends against pervasive monitoring > and other passive attacks (which are employed not only by nation > states). Even unauthenticated, encrypted communication (defined > below) is preferable to cleartext." > > This seems like it should be the first paragraph of Section 1.2. It is > rather out of place in Section 1.1. This is the conclusion of 1.1, based on the evidence presented above it, since 1.1 argues for optional authentication. > o Section 3: > "OS offers an incremental path to authenticated, encrypted communication > in the future, as suitable authentication technologies are deployed." > > As in Section 1, this text seems to assume one mode of operation for a > particular protocol. What about protocols that can already support > authenticated encryption? Doesn't OS offer an incremental path towards > using that mode right now, not in the future, for peers that already > support it? The text is intended to be read under the assumption that the protocol is substantially using cleartext today, OS enables unauth encryption now, and can enable authentication in the future. That is, the discussion is about opportunistic authentication, not mandatory authentication via local policy. There is very little present deployment of OS with authentication, for lack of downgrade resistant out-of-band signalling. Just a few medium size providers in Germany and some small enthusiast domains. This text can be made more clear. > o Section 3: > s/Communication should generally > be at least encrypted./At a minimum, communication should > generally be encrypted without authentication./ > > (I think this was the intention here, although I'm not completely sure > what "at least" means.) The interpretation is correct. A clearer update is possible. -- Viktor. From nobody Thu Sep 18 09:23:21 2014 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 1464B1A8864; Thu, 18 Sep 2014 09:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 Sr8_NXvvpOs7; Thu, 18 Sep 2014 09:23:17 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD541A889E; Thu, 18 Sep 2014 09:22:55 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8IGKwPA026257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Sep 2014 09:21:27 -0700 (PDT) Message-ID: <541B0669.1090304@isi.edu> Date: Thu, 18 Sep 2014 09:20:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , The IESG References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> In-Reply-To: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rBt9Z_t5jvptKPPxnACMo5VL0KU Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 16:23:19 -0000 On 9/17/2014 2:18 PM, Alia Atlas wrote: > Alia Atlas has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: No Objection ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- ... > Secondly, I am not fond of the term "Opportunistic Security" as compared > to "Opportunistic Encryption" if encryption is really all that is meant. FWIW, OE is already established as a term in RFC 4322, and AFAICT this document's definition would not be consistent with that one. Joe From nobody Thu Sep 18 09:26:52 2014 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 5900B1A887F; Thu, 18 Sep 2014 09:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 DYIUifbB7aj2; Thu, 18 Sep 2014 09:26:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E631A8877; Thu, 18 Sep 2014 09:26:39 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8IGPZmC027127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Sep 2014 09:25:44 -0700 (PDT) Message-ID: <541B0781.7020908@isi.edu> Date: Thu, 18 Sep 2014 09:25:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Stiemerling , Stephen Farrell References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> <85373C4B-BF9A-4431-9EED-C57E9ACBF49F@gmail.com> <541AC186.1090500@cs.tcd.ie> <541AEF8C.60704@gmail.com> In-Reply-To: <541AEF8C.60704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/soZ4jKTOC7hDJQHzOgLBVOE9Okk Cc: "saag@ietf.org" , "draft-dukhovni-opportunistic-security@tools.ietf.org" , The IESG Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 16:26:42 -0000 OS is about "do the best you can". BTNS was named in the same spirit of doing "better than nothing", but is just one of many specific mechanisms that might apply. If that's not coming across in the doc, it points to the clarity failure of the doc that others have noted. FWIW, I don't think citing specific examples does much to explain the notion of OS. Joe On 9/18/2014 7:43 AM, Martin Stiemerling wrote: > > > Am 18.09.14 um 13:27 schrieb Stephen Farrell: >> >> >> On 18/09/14 12:12, Martin Stiemerling wrote: >>> Hi Stephen, >>> >>> Thanks for reply. >>> >>> I wonder , if any reference to btns would be useful, sort of >>> historical evidence, or not. >> >> Mostly "not" I think:-) One of the reasons we ended up with >> Viktor's draft was (I think) that folks were somewhat worried >> that a bunch of the historic text in Steve Kent's draft [1] >> would bog us down in debate/recriminations/whatever. >> >> The stuff Viktor added about starttls [2] is I think enough >> of, and a better, demonstration that OS can be useful. And >> we don't need to try enumerate all past cases of OS either. >> So on balance I'd argue for not adding such. > > wfm. > >> >> Cheers, >> S. >> >> PS: That said, I do think that the historic text in Steve's >> draft would be useful to publish too somehow. I'm less sure >> I'd like another LC on this topic soon though;-) > > :) > > >> >> [1] https://tools.ietf.org/html/draft-kent-opportunistic-security >> [2] >> https://tools.ietf.org/html/draft-dukhovni-opportunistic-security-04#section-4 >> >> >> >>> >>> Thanks, >>> >>> Martin >>> >>> >>> >>>> On 16.09.2014, at 12:14, Stephen Farrell >>>> wrote: >>>> >>>> >>>> Hi Martin, >>>> >>>>> On 16/09/14 10:37, Martin Stiemerling wrote: >>>>> Martin Stiemerling has entered the following ballot position for >>>>> draft-dukhovni-opportunistic-security-04: No Record >>>>> >>>>> When responding, please keep the subject line intact and reply to all >>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>> this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here: >>>>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I am not done with my review, but in the meanwhile I have question: >>>>> >>>>> How does this draft related to the old Better-Than-Nothing Security >>>>> (btns) working group [1] and their output? >>>> >>>> I think its fair to say this LC discussion involved some of the >>>> same protagonists and some of the same arguments. >>>> >>>> Hopefully this RFC would short-circuit a part of the debate >>>> that happened back then (*) but more recently in the httpbis WG. >>>> There was also a bit of that debate in chartering tcpinc. >>>> >>>> The debate that this ought short-circuit is the part about >>>> the overall legitimacy of the approach. So this draft should >>>> save time, energy and good-will when an OS approach is proposed >>>> for other protocols - that part of the discussion seems to me >>>> at least to be contentious, so that can be a non-trivial saving. >>>> >>>> Functionally, I think one could describe the output from BTNS >>>> as following the OS design pattern, but not that successfully. >>>> (The lack of success conclusion being based on the lack of >>>> deployment, it'd probably not be productive to try analyse >>>> the reasons for that further right now - see below.) >>>> >>>> Some of those involved in BTNS have been working on another go >>>> at applying the OS approach to IPsec. That work has not yet >>>> been chartered anywhere but we have had a couple of updates >>>> at saag sessions [2] ([2] btw doesn't use the OS term - it >>>> was done while we were still flailing about with imperfect >>>> term selection;-) If that work got sufficient traction to be >>>> chartered, then this draft should help with that, again by >>>> legitimising the design pattern. The discussion as to why >>>> BTNS wasn't successful, and why some proposed new work might >>>> succeed, would of course still need to be had at chartering >>>> time. >>>> >>>> Hope that covers it, >>>> Cheers, >>>> S. >>>> >>>> [2] https://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf >>>> >>>> (*) I wasn't involved in BTNS really, other than to watch the >>>> fireworks from the sidelines. From that perspective, I think that >>>> history probably explains some of the difficulty getting agreement >>>> with this draft. >>>> >>>> >>>>> >>>>> [1] http://www.ietf.org/wg/concluded/btns.html >>>>> >>>>> >>> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Sep 18 09:31:14 2014 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 D952C1A041F; Thu, 18 Sep 2014 09:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 vYATSGlOzQfs; Thu, 18 Sep 2014 09:31:11 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1A251A02FE; Thu, 18 Sep 2014 09:31:11 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8IGUSIw028065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Sep 2014 09:30:37 -0700 (PDT) Message-ID: <541B08A6.1080005@isi.edu> Date: Thu, 18 Sep 2014 09:30:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ted Lemon , The IESG References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> In-Reply-To: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/qiDJX4EoeDxfjGNylvXswfe-r30 Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 16:31:13 -0000 On 9/18/2014 3:29 AM, Ted Lemon wrote: > Ted Lemon has entered the following ballot position for > draft-dukhovni-opportunistic-security-04: Discuss ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I think this document needs to state explicitly that opportunistic > security is _not_ appropriate in the same set of applications as > mandatory security. E.g., we never want "opportunistic security" when > connecting to the bank, or doing a credit card transaction. We want > mandatory security. ... AFAICT you want a mandatory minimum. That may or may not include ID-free methods (e.g., BTNS), it may or may not include channel binding and higher-level authentication, etc. AFAICT, OS isn't about just using BTNS-style mechanisms; it appears to be about being inclusive of a range of alternatives that the app should constrain. If the doc isn't clear on that point (either agreeing or refuting), it should be. Joe From nobody Thu Sep 18 10:04:44 2014 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 E59C01A050E for ; Thu, 18 Sep 2014 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NX2xTditec0M; Thu, 18 Sep 2014 10:04:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 821041A04AF; Thu, 18 Sep 2014 10:04:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140918170415.16101.61435.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 10:04:15 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/saag/fcEv0vN4-UJT0QsGrIt4X8IuQhc Subject: [saag] ID Tracker State Update Notice: X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 17:04:42 -0000 IESG state changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ From nobody Thu Sep 18 10:13:32 2014 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 D11151A048E; Thu, 18 Sep 2014 10:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 iQgtPtxl57Vq; Thu, 18 Sep 2014 10:13:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50C1A04A6; Thu, 18 Sep 2014 10:13:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 85CB5BE87; Thu, 18 Sep 2014 18:13:27 +0100 (IST) 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 AK4UvIMSBGsB; Thu, 18 Sep 2014 18:13:25 +0100 (IST) Received: from [10.87.48.4] (unknown [86.41.49.218]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3BD65BE80; Thu, 18 Sep 2014 18:13:25 +0100 (IST) Message-ID: <541B12B4.9020706@cs.tcd.ie> Date: Thu, 18 Sep 2014 18:13:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: IESG , ietf-dane@dukhovni.org, draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org References: <20140918170415.16101.61435.idtracker@ietfa.amsl.com> In-Reply-To: <20140918170415.16101.61435.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/5JlTCRjj2Bndwh62H6tzNdIUJwY Subject: Re: [saag] ID Tracker State Update 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, 18 Sep 2014 17:13:31 -0000 IESG folks, Just to summarise the plan in text: - The -03 to -04 transition is clearly problematic for enough IESG folks that we should revisit it; - Pete has offered to help Viktor in editing a -05 and - Barry will help Paul with issue tracking in yet another extension of the last call; - Issues that have been raised on the list before and dealt with will not be considered in that extension of the LC - The LC extension will start when -05 is published (with IESG comments on -04 handled) and will run for 2 weeks. - After the LC, the IESG will decide whether reballoting is required or not. Thanks for your comments and esp. to Pete, Barry, Paul and Viktor for being willing to do more work to get this over the line. Cheers, S. PS: For the saag list: I think best for now is to let Pete and Viktor do the work on the -05 version with the IESG and to not discuss this more just now until that's done. (But you'll all of course send whatever mail you want, so not sure why I bother asking really:-) On 18/09/14 18:04, IETF Secretariat wrote: > IESG state changed to IESG Evaluation - Defer::AD Followup from IESG Evaluation - Defer > ID Tracker URL: http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Thu Sep 18 10:37:41 2014 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 8002D1A888B; Thu, 18 Sep 2014 10:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] 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 Y7_NwjuH4ZZ4; Thu, 18 Sep 2014 10:37:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F131A8891; Thu, 18 Sep 2014 10:37:08 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8IHaMCT013496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Sep 2014 10:36:22 -0700 (PDT) Message-ID: <541B1816.9080507@isi.edu> Date: Thu, 18 Sep 2014 10:36:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Richard Barnes , Stephen Farrell References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0LyFpwLey3_WKglsh374JXGNvrI Cc: Martin Stiemerling , The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, IETF SAAG Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 17:37:38 -0000 On 9/17/2014 7:35 PM, Richard Barnes wrote: > My understanding is that BTNS ran up against the major hard problem for > OS -- how do you combine it with real, non-opportunistic security? > (Without enabling downgrade attacks.) I think there is a lot of confusion between BTNS and OS. AFAICT (and yes, the doc is not clear on this), OS is about using a spectrum of solutions, one of which may be BTNS. BTNS was a specific solution that valued the utility of IPsec using Diffie-Hellman in the absence of identity validation. OS is not BTNS, but BTNS can be part of OS. That's just my viewpoint, but if others agree, then that ought to be made clear (and cited) in the document. I do think that BTNS is a key part of the OS spectrum and should be cited. As to why was BTNS not more widely deployed, there are many potential reasons, but it's difficult to establish a negative. I agree with Nico that BTNS with connection latching might have had better uptake, but I don't think that explains why BTNS without connection latching didn't. IMO, BTNS was just too early and there was not enough appreciation at the time for security without identity authentication. Joe From nobody Thu Sep 18 12:34:19 2014 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 8CC111A096C; Thu, 18 Sep 2014 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 OU2UeYrSy4dU; Thu, 18 Sep 2014 12:34:17 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 044CB1A069C; Thu, 18 Sep 2014 12:34:17 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id D85F5678062; Thu, 18 Sep 2014 12:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HH4S2HZ/RyOp29 7GJ7A6Lyr55Og=; b=fBZD90AG4UJlR6Lmk2ouEsi14mTkmTRSzozLK4KPob8FCU bzgNhP7f+EW8RCRIDTCiuxAoIhYqEkPAKCZpT5Mt/4iKDXo584YATuXncmeUw8t9 9wD1xnC4x+yOBFPhejRS1rX66NKjRCvIZ7lmg4oRy1KBb7BOG/oqp9XuW95xc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 5B513678057; Thu, 18 Sep 2014 12:34:16 -0700 (PDT) Date: Thu, 18 Sep 2014 14:34:15 -0500 From: Nico Williams To: Joe Touch Message-ID: <20140918193413.GF4071@localhost> References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541B0669.1090304@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GTBObozDBYOO6dHOtcC8LhAcSn8 Cc: saag@ietf.org, The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, Alia Atlas Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 19:34:17 -0000 On Thu, Sep 18, 2014 at 09:20:57AM -0700, Joe Touch wrote: > On 9/17/2014 2:18 PM, Alia Atlas wrote: > >Alia Atlas has entered the following ballot position for > >draft-dukhovni-opportunistic-security-04: No Objection > ... > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > ... > >Secondly, I am not fond of the term "Opportunistic Security" as compared > >to "Opportunistic Encryption" if encryption is really all that is meant. > > FWIW, OE is already established as a term in RFC 4322, and AFAICT > this document's definition would not be consistent with that one. The other reason to not use OE is that "encryption" doesn't denote as much as "security". In particular it doesn't denote "authentication", but OS can provide it -- OS need not always merely ephemeral-ephemeral Diffie-Hellman key agreement! Nico -- From nobody Thu Sep 18 12:39:15 2014 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 B56FD1A06F8; Thu, 18 Sep 2014 12:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 C8AkPs36rZZm; Thu, 18 Sep 2014 12:39:11 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EFA661A04E7; Thu, 18 Sep 2014 12:39:10 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id CF4752007D831; Thu, 18 Sep 2014 12:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HyFZOpi+pZ2P4M kowP8O0d+Op5g=; b=WxlwGVa0YfXae8x2SGuk/CFxjf3LwwnDog35BZngzOZJRr 1W8QCihX2FiRvgg8sQlBrp33TfRu0GhqVtPWLHKp8PZnISyeWfXkWTNSvsY4Y1J7 e6Nbmo3/28O8vP9PQFCHP6iiu5dqkZDFvzYklnsaCRYh/vzbA1TXvQu1x1Kig= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 39D762007D82E; Thu, 18 Sep 2014 12:39:10 -0700 (PDT) Date: Thu, 18 Sep 2014 14:39:09 -0500 From: Nico Williams To: Joe Touch Message-ID: <20140918193907.GG4071@localhost> References: <20140916093701.16207.8261.idtracker@ietfa.amsl.com> <54180D8E.6070706@cs.tcd.ie> <541B1816.9080507@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541B1816.9080507@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FnP_vZtJHYoMAhTGUToo124Y6Eo Cc: Martin Stiemerling , IETF SAAG , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Martin Stiemerling's No Record on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 18 Sep 2014 19:39:11 -0000 On Thu, Sep 18, 2014 at 10:36:22AM -0700, Joe Touch wrote: > I think there is a lot of confusion between BTNS and OS. > > AFAICT (and yes, the doc is not clear on this), OS is about using a > spectrum of solutions, one of which may be BTNS. > > BTNS was a specific solution that valued the utility of IPsec using > Diffie-Hellman in the absence of identity validation. > > OS is not BTNS, but BTNS can be part of OS. That's just my viewpoint, > but if others agree, then that ought to be made clear (and cited) in the > document. I do think that BTNS is a key part of the OS spectrum and > should be cited. +1 > As to why was BTNS not more widely deployed, there are many potential > reasons, but it's difficult to establish a negative. > > I agree with Nico that BTNS with connection latching might have had > better uptake, but I don't think that explains why BTNS without > connection latching didn't. That's true, BTNS could have been deployed without connection latching, and it would have added some value where the alternative was cleartext. BTNS adds much more value with connection latching in the picture though. Thinking about how to apply DANE to IPsec it's clear that a simpler scheme than connection latching get much the same semantics when both peers have TLSA RRs, but when at least one of the peers is anonymous it's difficult to see how to get sane security semantics more simply than with connection latching. > IMO, BTNS was just too early and there was not enough appreciation at > the time for security without identity authentication. Agreed. At the time I thought of, and dismissed in my mind, the use of DNSSEC: it seemed too early. But BTNS was just too early (though IMO connection latching should have been present from day one of moden IPsec). Nico -- From nobody Thu Sep 18 12:41:10 2014 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 AF1481A06DF; Thu, 18 Sep 2014 12:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 bgekncT1fDLf; Thu, 18 Sep 2014 12:41:06 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 13CC41A070A; Thu, 18 Sep 2014 12:41:06 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id D9A8259805F; Thu, 18 Sep 2014 12:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HOeS3OByJ5f7AR 4NeHs/hLYT0Go=; b=FfJ/iAs7jFgX9Tt7INfuF8cX6BdaLwPlEDQJQYuiC0RS/1 dT3dfoJmp/3X/Q8d+OzixpNLe36a31abceNRluBrRukrsRZjl4Qw5fC3tD1zixsY vPnSKoVtH4ZFovOTcXGULxErWQE7gg69UEOTM4s7wZZxD521wPhNPXJIJkY9Q= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 5EF67598058; Thu, 18 Sep 2014 12:41:05 -0700 (PDT) Date: Thu, 18 Sep 2014 14:41:04 -0500 From: Nico Williams To: Joe Touch Message-ID: <20140918194102.GH4071@localhost> References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> <541B08A6.1080005@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541B08A6.1080005@isi.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/uu6exIDMXaqttv0RIJcN5Nv32Wg Cc: saag@ietf.org, Ted Lemon , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 19:41:06 -0000 On Thu, Sep 18, 2014 at 09:30:30AM -0700, Joe Touch wrote: > On 9/18/2014 3:29 AM, Ted Lemon wrote: > >Ted Lemon has entered the following ballot position for > >draft-dukhovni-opportunistic-security-04: Discuss > ... > >---------------------------------------------------------------------- > >DISCUSS: > >---------------------------------------------------------------------- > > > >I think this document needs to state explicitly that opportunistic > >security is _not_ appropriate in the same set of applications as > >mandatory security. E.g., we never want "opportunistic security" when > >connecting to the bank, or doing a credit card transaction. We want > >mandatory security. > ... > > AFAICT you want a mandatory minimum. That may or may not include > ID-free methods (e.g., BTNS), it may or may not include channel > binding and higher-level authentication, etc. > > AFAICT, OS isn't about just using BTNS-style mechanisms; it appears > to be about being inclusive of a range of alternatives that the app > should constrain. OS does set a mandatory minimum: the lowest common denominator between local capabilities and a peer's discovered/advertised capabilities. Nico -- From nobody Thu Sep 18 12:54:43 2014 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 5DEC31A0AED; Thu, 18 Sep 2014 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 L9KNZciBba3Y; Thu, 18 Sep 2014 12:54:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A28A1A88B0; Thu, 18 Sep 2014 12:54:40 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s8IJsJUJ009295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Sep 2014 12:54:19 -0700 (PDT) Message-ID: <541B386C.6050501@isi.edu> Date: Thu, 18 Sep 2014 12:54:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Nico Williams References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> <541B08A6.1080005@isi.edu> <20140918194102.GH4071@localhost> In-Reply-To: <20140918194102.GH4071@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ufYlvMoRmOZlsciLA0-17Xn_dyM Cc: saag@ietf.org, Ted Lemon , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 19:54:41 -0000 On 9/18/2014 12:41 PM, Nico Williams wrote: > On Thu, Sep 18, 2014 at 09:30:30AM -0700, Joe Touch wrote: >> On 9/18/2014 3:29 AM, Ted Lemon wrote: >>> Ted Lemon has entered the following ballot position for >>> draft-dukhovni-opportunistic-security-04: Discuss >> ... >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> I think this document needs to state explicitly that opportunistic >>> security is _not_ appropriate in the same set of applications as >>> mandatory security. E.g., we never want "opportunistic security" when >>> connecting to the bank, or doing a credit card transaction. We want >>> mandatory security. >> ... >> >> AFAICT you want a mandatory minimum. That may or may not include >> ID-free methods (e.g., BTNS), it may or may not include channel >> binding and higher-level authentication, etc. >> >> AFAICT, OS isn't about just using BTNS-style mechanisms; it appears >> to be about being inclusive of a range of alternatives that the app >> should constrain. > > OS does set a mandatory minimum: the lowest common denominator between > local capabilities and a peer's discovered/advertised capabilities. That's a minimum of what is possible, certainly. A mandatory minimum would be established by the "consumer", i.e., the app - i.e., do at least this much or don't bother setting up a connection at all. Joe From nobody Thu Sep 18 13:06:25 2014 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 7FEAE1A88E8; Thu, 18 Sep 2014 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] 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 B9CWPFV35ulS; Thu, 18 Sep 2014 13:06:15 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 72F0F1A88EE; Thu, 18 Sep 2014 13:05:59 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 2071B1B4058; Thu, 18 Sep 2014 13:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=emwhF25s4fNxYYcjHZcj lBETDeM=; b=nkl/hnSPLxWvzZsqFXsSlb+EClgjTiXlT/gBDie7mVC79Xgm6A/H OZabafyGY/bzQVifGqayfnrJHuB+uhBJgh/CxqtqL0sayWtxiL8QYR8zFn+6NjUS XsVWr13WENSCutkDZtKX76b/w6EqFCiDN3UecKPddoZvZPhxev+08cg= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 9DE471B406B; Thu, 18 Sep 2014 13:05:58 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p10so1467841wes.30 for ; Thu, 18 Sep 2014 13:05:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.174.163 with SMTP id bt3mr4084505wjc.4.1411070757317; Thu, 18 Sep 2014 13:05:57 -0700 (PDT) Received: by 10.216.32.135 with HTTP; Thu, 18 Sep 2014 13:05:57 -0700 (PDT) In-Reply-To: <541B386C.6050501@isi.edu> References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> <541B08A6.1080005@isi.edu> <20140918194102.GH4071@localhost> <541B386C.6050501@isi.edu> Date: Thu, 18 Sep 2014 15:05:57 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/g_vJfdu7oRaUPuhsH_KZ-ANMITQ Cc: "saag@ietf.org" , Ted Lemon , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 18 Sep 2014 20:06:16 -0000 On Thu, Sep 18, 2014 at 2:54 PM, Joe Touch wrote: > On 9/18/2014 12:41 PM, Nico Williams wrote: >> On Thu, Sep 18, 2014 at 09:30:30AM -0700, Joe Touch wrote: >>> AFAICT, OS isn't about just using BTNS-style mechanisms; it appears >>> to be about being inclusive of a range of alternatives that the app >>> should constrain. >> >> OS does set a mandatory minimum: the lowest common denominator between >> local capabilities and a peer's discovered/advertised capabilities. > > That's a minimum of what is possible, certainly. A mandatory minimum would > be established by the "consumer", i.e., the app - i.e., do at least this > much or don't bother setting up a connection at all. Yes, of course, local policy (and, of course, application protocol specs) set a minimum. OS can only raise that minimum, not lower it. The I-D does say this. From nobody Fri Sep 19 03:20:43 2014 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 03AC21A00AA; Fri, 19 Sep 2014 03:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 9Fsh8Er8Q7ZA; Fri, 19 Sep 2014 03:20:38 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F051A00A8; Fri, 19 Sep 2014 03:20:38 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 861891B855D; Fri, 19 Sep 2014 03:20:38 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 552D553E074; Fri, 19 Sep 2014 03:20:38 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Sep 2014 03:20:38 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 19 Sep 2014 06:20:26 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> <541B08A6.1080005@isi.edu> <20140918194102.GH4071@localhost> <541B386C.6050501@isi.edu> To: Nico Williams X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EVnYXrz2cSnTi8p8FkrgPrdsamI Cc: The IESG , "saag@ietf.org" , draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 19 Sep 2014 10:20:40 -0000 On Sep 18, 2014, at 4:05 PM, Nico Williams = wrote: > Yes, of course, local policy (and, of course, application protocol > specs) set a minimum. OS can only raise that minimum, not lower it. > The I-D does say this. There is text in the document that talks about local policy. There is = absolutely no chance that a non-security-expert reading that would take = it to mean what I said. And furthermore, local policy doesn't help if = there is no secure way in the protocol to say "encryption is mandatory = for this connection." So this isn't responsive to the point I raised. I think I was pretty clear in my DISCUSS point, but just to be clearer, = it has to be the case that the _client_ can't both know about the = possibility of connecting to a security-is-mandatory resource _and_ be = fooled about the mandatoryness of security for that resource. IOW, we = do not want to get rid of https://. I don't think the authors of this document want to get rid of https://. = I just think that the document needs to be clearer about that. From nobody Fri Sep 19 06:02:17 2014 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 1F00D1A012D; Fri, 19 Sep 2014 06:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 fhw9EzUzkYoX; Fri, 19 Sep 2014 06:02:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DCC1A0127; Fri, 19 Sep 2014 06:02:13 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8JD29dX001245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 06:02:13 -0700 Message-ID: <541C294A.3010708@dcrocker.net> Date: Fri, 19 Sep 2014 06:02:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> In-Reply-To: <541B0669.1090304@isi.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Sep 2014 06:02:13 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4GY2sW11v8yHo5vtHAC8GZNtk2M Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 13:02:15 -0000 On 9/18/2014 9:20 AM, Joe Touch wrote: > FWIW, OE is already established as a term in RFC 4322, and AFAICT this > document's definition would not be consistent with that one. It's not as if that previous usage has gained much community traction, nor has the work it is part of. For that matter, the term is not essential to that work, in spite of being in the RFC's title. We update and obsolete specifications; why not do that for terminology that has no existing momentum? So it would not be that disruptive to tweak the term for this newer use, in order to get a label that is obvious and accurate, rather than one that is obscure and misleading. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 19 06:05:55 2014 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 2B7621A0144; Fri, 19 Sep 2014 06:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 YB079Wq3gWNC; Fri, 19 Sep 2014 06:05:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CB0CF1A013B; Fri, 19 Sep 2014 06:05:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 813EBBE33; Fri, 19 Sep 2014 14:05:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Crt8eB2UsNph; Fri, 19 Sep 2014 14:05:48 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5C157BE03; Fri, 19 Sep 2014 14:05:48 +0100 (IST) Message-ID: <541C2A2D.2080300@cs.tcd.ie> Date: Fri, 19 Sep 2014 14:05:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <541C294A.3010708@dcrocker.net> In-Reply-To: <541C294A.3010708@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/X6BHVYIOxzZnveCgEfElZ_FoL8c Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, saag@ietf.org Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 19 Sep 2014 13:05:53 -0000 On 19/09/14 14:02, Dave Crocker wrote: > On 9/18/2014 9:20 AM, Joe Touch wrote: >> FWIW, OE is already established as a term in RFC 4322, and AFAICT this >> document's definition would not be consistent with that one. > > > It's not as if that previous usage has gained much community traction, > nor has the work it is part of. For that matter, the term is not > essential to that work, in spite of being in the RFC's title. We update > and obsolete specifications; why not do that for terminology that has no > existing momentum? > > So it would not be that disruptive to tweak the term for this newer use, > in order to get a label that is obvious and accurate, rather than one > that is obscure and misleading. Please. That has been discussed to death. I really wish folks (not just you Dave) would stop attempting to find yet another term that will not garner any better consensus. There is plenty of mail on exactly this unproductive topic already. I recommend people who want to suggest new terms go read that. S. > > d/ > From nobody Fri Sep 19 06:32:58 2014 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 386E51A0175; Fri, 19 Sep 2014 06:32:57 -0700 (PDT) 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, 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 riTgR22QsWOD; Fri, 19 Sep 2014 06:32:51 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069311A016E; Fri, 19 Sep 2014 06:32:50 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id p9so2575376lbv.3 for ; Fri, 19 Sep 2014 06:32:49 -0700 (PDT) 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:cc:content-type; bh=epx/GVSuMo/sCtt/FZDwz7R0pXrLmVV72huD6hp+UMU=; b=Nxj5cSfc9PSETFVzMLWVBIkUL/PWBJE7Kv/tAGxirOJMLDJNv9GcHBfgJgAhtr0NuJ Occ4HM3ZFEv+ubUcblIvafDuwaeUDXF+QZxcVhCtj4Ryy8DxQNy8ILo5lyEqliS04rCI q8BBeVfjsel303x04/iVGmX9ORy1FtoYEszc7FOfm+kT2S52OsZ9Dn5ntJ0SQCfb+dLJ Dz4wqm9qOm9pH0GSQz31DWMhs3wWmdpwrjZI3TOgw5Tf6W64hWokB1J4Vb6ju1UDGyKw fHH8EAOkFd7hJHsj+66nS+Wy0UD8kqzj1KU7tD8qTFLkR1iSAWIvfN8RxuibWPlel+3x JBNw== MIME-Version: 1.0 X-Received: by 10.112.142.104 with SMTP id rv8mr6217969lbb.59.1411133569270; Fri, 19 Sep 2014 06:32:49 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.1.193 with HTTP; Fri, 19 Sep 2014 06:32:49 -0700 (PDT) In-Reply-To: <541C294A.3010708@dcrocker.net> References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <541C294A.3010708@dcrocker.net> Date: Fri, 19 Sep 2014 09:32:49 -0400 X-Google-Sender-Auth: CDhGp5X2HcnLwOz8jZyCMN2pAcI Message-ID: From: Barry Leiba To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4_l1_jQy-neokBWzfC5CteNacJk Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org, "saag@ietf.org" Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 19 Sep 2014 13:32:57 -0000 >> FWIW, OE is already established as a term in RFC 4322, and AFAICT this >> document's definition would not be consistent with that one. > > It's not as if that previous usage has gained much community traction, > nor has the work it is part of. For that matter, the term is not > essential to that work, in spite of being in the RFC's title. We update > and obsolete specifications; why not do that for terminology that has no > existing momentum? > > So it would not be that disruptive to tweak the term for this newer use, > in order to get a label that is obvious and accurate, rather than one > that is obscure and misleading. Dave, I agree with you fully, as noted in my ballot comment. But, as also noted in my ballot comment, this one's been discussed and settled. I'm sad about the result, and I think the reasons for the decision are weak, but on this point I think we *do* have rough consensus, and you and I are in the rough. Barry From nobody Fri Sep 19 06:54:02 2014 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 B7C031A0127; Fri, 19 Sep 2014 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 PYa0Wn4W63dU; Fri, 19 Sep 2014 06:53:51 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA2D1A0142; Fri, 19 Sep 2014 06:53:51 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE2FB1B855B; Fri, 19 Sep 2014 06:53:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A564953E074; Fri, 19 Sep 2014 06:53:50 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Sep 2014 06:53:44 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <541C2A2D.2080300@cs.tcd.ie> Date: Fri, 19 Sep 2014 09:53:28 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <541C294A.3010708@dcrocker.net> <541C2A2D.2080300@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ZCyulKErtAWtCXQ_ziy2A6fjCEo Cc: saag@ietf.org, dcrocker@bbiw.net, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 19 Sep 2014 13:53:56 -0000 On Sep 19, 2014, at 9:05 AM, Stephen Farrell = wrote: > Please. That has been discussed to death. I really wish folks > (not just you Dave) would stop attempting to find yet another > term that will not garner any better consensus. There is plenty > of mail on exactly this unproductive topic already. I recommend > people who want to suggest new terms go read that. OS is a lousy acronym. It means "operating system" or "open source." = It doesn't need a new meaning. I agree that OE is not the right word, = but I disagree that this discussion is useless. I proposed a better = term, "opportunistic protection" in my comment during IESG review. = It's not better spelled out, but it makes a better acronym. Whether = that's worth making a change for I don't know, but saying that there = isn't a problem here isn't correct; the question is whether the problem = should be addressed by saying "from among the bad choices we have, we = prefer OS" or "from among the bad choices we have, we prefer ." From nobody Fri Sep 19 07:27:37 2014 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 B41281A01C3; Fri, 19 Sep 2014 07:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, GB_I_LETTER=-2] 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 ThtkOFlwBQig; Fri, 19 Sep 2014 07:27:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101661A019C; Fri, 19 Sep 2014 07:27:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 746802AAC74; Fri, 19 Sep 2014 14:27:24 +0000 (UTC) Date: Fri, 19 Sep 2014 14:27:24 +0000 From: Viktor Dukhovni To: "saag@ietf.org" Message-ID: <20140919142724.GZ26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140918135234.GB26920@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/QSUN-GBKvMVJbxqqp-aD1NcPoDg Cc: iesg@ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, iesg@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:27:29 -0000 On Fri, Sep 19, 2014 at 06:20:26AM -0400, Ted Lemon wrote: > On Sep 18, 2014, at 4:05 PM, Nico Williams wrote: > > Yes, of course, local policy (and, of course, application protocol > > specs) set a minimum. OS can only raise that minimum, not lower it. > > The I-D does say this. > > There is text in the document that talks about local policy. There is > absolutely no chance that a non-security-expert reading that would take > it to mean what I said. And furthermore, local policy doesn't help if > there is no secure way in the protocol to say "encryption is mandatory > for this connection." So this isn't responsive to the point I raised. You, others and I are I think in complete agreement as to when OS is not applicable, so the question as I understand it is whether the text sufficiently captures that agreement. I had hoped that the last paragraph above subsection 1.1 and the first principle would adequately address this point. 1. ... OS is not intended as a substitute for authenticated, encrypted communication when such communication is already mandated by policy or is otherwise required to access a particular resource. In essence, OS is employed when one might otherwise settle for cleartext (or the minimum protection possible if the protocol is always encrypted). OS protocols never preempt local security policies. A security administrator may specify security policies that override OS. For example, a policy might require authenticated, encrypted communication, in contrast to the default OS security policy. 1.1. ... 3. ... Coexist with local policy: Local security policies preempt OS. Opportunistic security never displaces or preempts local policy. Many applications and types of data are too sensitive to use OS, and more traditional security designs are appropriate in such cases. There were similar concerns during LC, and the text was amplified to address those concerns. > I think I was pretty clear in my DISCUSS point, but just to be clearer, > it has to be the case that the _client_ can't both know about the > possibility of connecting to a security-is-mandatory resource _and_ be > fooled about the mandatoryness of security for that resource. IOW, we > do not want to get rid of https://. Indeed I consider "https://" URIs to be such local policy. Hence the phrase "or is otherwise required to access a particular resource" at in the paragraph above 1.1. > I don't think the authors of this document want to get rid of https://. > I just think that the document needs to be clearer about that. Absolutely correct, there is a well known security policy associated with an "https" URI, and OS does not preempt that policy. With browsers OS could only apply to "http://" and/or any other URI schemes where it may be appropriate. In response to the DISCUSS I previously sent the below. Are you looking for a more detailed exposition of what "local policy" means? Would that be examples like "https://" or per destination TLS policy tables in an MTA, a more detailed general description, or both? > On Thu, Sep 18, 2014 at 03:29:37AM -0700, Ted Lemon wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think this document needs to state explicitly that opportunistic > > security is _not_ appropriate in the same set of applications as > > mandatory security. > > This is difficult to explain, since an MTA is an application, and > typically supports different policies for different destinations, > with a default policy for the rest. > > > E.g., we never want "opportunistic security" when > > connecting to the bank, or doing a credit card transaction. > > Absolutely, but sadly for most users connecting to the bank is not > a different "application", it's all in the browser. However, > "https://..." URIs specify a security policy that OS does not > preempt. > > I think that the first design principle adequately covers this. > > > We want mandatory security. > > Absolutely. This is, for example, also discussed in the DANE SMTP > draft which specifically leaves room for mandatory policy, possibly > with authentication via DANE or via locally configured public CAs. > > > I think that is so obvious to the security folks > > that nobody thought to mention it, but it must be stated in large > > friendly letters both in the introduction and in the security > > considerations section, because this document will be read by > > non-security-geeks. > > ... and because local security policies take precedence over the default OS > policy ... > > While the use of OS is preempted by a non-OS local policy, ... > > > You should also advise that documents that describe > > implementations of opportunistic security should mention this in _their_ > > security considerations section. An opportunistically secure protocol > > that can be MiTM'd to look secure on the server end whilst being in > > cleartext on the client end would be disastrous in such contexts. > > > > The DANE SMTP document currently has: > > The protocol does not preclude existing non-opportunistic SMTP > TLS security arrangements, which can continue to be used as > before via manual configuration ... > > > > In section 5: > > > > When protection only against passive attacks is negotiated over a > > channel vulnerable to active downgrade attacks, and the use of > > encryption fails, a protocol might elect non-intrusive fallback to > > cleartext. An active attacker could equally have suppressed the use > > of encryption during negotiation, so failure to encrypt may be more > > often a symptom of an interoperability problem than an active attack. > > > > The last sentence doesn't make sense?the first half of the statement > > doesn't actually imply the second half as a conclusion, as the "so" in > > the middle would suggest. > > Yes, the point is that not falling back does not help, and therefore, > one might as well (when operationally necessary) enable fallback, > since the active attacker is not deterred by lack of fallback. > This can be stated more explicitly. > > > > It implies the opposite. I don't think you > > are saying anything wrong here, but you need to clean this text up, > > because as written it doesn't make sense. > > Got it. -- Viktor. From nobody Fri Sep 19 07:36:48 2014 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 139281A020B; Fri, 19 Sep 2014 07:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_JBpH2ma938; Fri, 19 Sep 2014 07:36:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018C31A01C3; Fri, 19 Sep 2014 07:36:29 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8JEaPNm006014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 07:36:28 -0700 Message-ID: <541C3F61.4090600@bbiw.net> Date: Fri, 19 Sep 2014 07:36:17 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <20140918193413.GF4071@localhost> In-Reply-To: <20140918193413.GF4071@localhost> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Fri, 19 Sep 2014 07:36:28 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/8zf92jJFoMpWBBsx6rAVXpiJrNo Cc: The IESG , draft-dukhovni-opportunistic-security@tools.ietf.org Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 19 Sep 2014 14:36:41 -0000 On 9/18/2014 12:34 PM, Nico Williams wrote: >> On 9/17/2014 2:18 PM, Alia Atlas wrote: ... >>> Secondly, I am not fond of the term "Opportunistic Security" as compared >>> to "Opportunistic Encryption" if encryption is really all that is meant. ... > The other reason to not use OE is that "encryption" doesn't denote as > much as "security". In particular it doesn't denote "authentication", In this opportunistic context, any use of authentication is solely in the service of a better encryption mechanism. In this context, authentication has no life on its own. For all of the many concerns expressed about the writing of the current draft, this one point is nonetheless entirely clear. Challenges to the use of 'opportunistic security' continue to be raised by one person after another, because it's a terrible choice. This ought to give pause to anyone claiming that the choice of term has been 'settled'... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 19 07:44:52 2014 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 5650A1A01DD; Fri, 19 Sep 2014 07:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 oZwiJbMWkK5p; Fri, 19 Sep 2014 07:44:44 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983DD1A01DC; Fri, 19 Sep 2014 07:44:44 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id z6so627516yhz.4 for ; Fri, 19 Sep 2014 07:44:44 -0700 (PDT) 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=vKqn4DlrgVzXITZbjknMmSe7RnOBO4HJmMr+tLlVY68=; b=qTsUFnpxm7N+BYnMjVhr5VSEQ/jH1dI0RuicX534auXwDL3BlRyRQI5iHI8Nv4qxHK OznVNN/PdbbTP7SKFIFfO7q8Rt5ffordQd+Nz31w8yghUrHMOjCgfaajXB9WyWQ+qXfz 2GWHsX51NRMLUg19gO7HXOdbPV4jnOwKS1VB5TsOmj9tM0PdYIWYzShW+eXgtMIUhyCS GJmAyrGJoZyAzEvisqJaBHpwhmBot/3mHzzq2es/h0jvODlDHp05ngCURHEcpkiigrfg h5QznWh9PtbXoHpbjsvPMIF52wduJawyL5S7n+c+juxDEPBce30V8tCjS5v8pVQ5EGd3 QHmg== MIME-Version: 1.0 X-Received: by 10.236.70.105 with SMTP id o69mr951989yhd.25.1411137883872; Fri, 19 Sep 2014 07:44:43 -0700 (PDT) Received: by 10.170.110.72 with HTTP; Fri, 19 Sep 2014 07:44:43 -0700 (PDT) In-Reply-To: <541C3F61.4090600@bbiw.net> References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <20140918193413.GF4071@localhost> <541C3F61.4090600@bbiw.net> Date: Fri, 19 Sep 2014 10:44:43 -0400 Message-ID: From: Alia Atlas To: Dave Crocker Content-Type: multipart/alternative; boundary=089e016355d84c243005036c2496 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rO3nhUwpvxCG2N4RQ2FYCmKpplI Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 19 Sep 2014 14:44:46 -0000 --089e016355d84c243005036c2496 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 19, 2014 at 10:36 AM, Dave Crocker wrote: > On 9/18/2014 12:34 PM, Nico Williams wrote: > >> On 9/17/2014 2:18 PM, Alia Atlas wrote: > ... > >>> Secondly, I am not fond of the term "Opportunistic Security" as > compared > >>> to "Opportunistic Encryption" if encryption is really all that is > meant. > ... > > The other reason to not use OE is that "encryption" doesn't denote as > > much as "security". In particular it doesn't denote "authentication", > > > In this opportunistic context, any use of authentication is solely in > the service of a better encryption mechanism. In this context, > authentication has no life on its own. > > For all of the many concerns expressed about the writing of the current > draft, this one point is nonetheless entirely clear. > > Challenges to the use of 'opportunistic security' continue to be raised > by one person after another, because it's a terrible choice. This ought > to give pause to anyone claiming that the choice of term has been > 'settled'... I am not going to comment further on the selection of the term, whether opportunistic security or opportunistic encryption. My concern that opportunistic security implied more than opportunistic encryption was answered by Stephen's comment that additional types of security protection (e.g. replay) could also be opportunistically offered depending upon the protocol and be included in the ideas in this draft. Alia > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > --089e016355d84c243005036c2496 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 19, 2014 at 10:36 AM, Dave Crocker <dcrocker@bbiw.net&= gt; wrote:
On 9/1= 8/2014 12:34 PM, Nico Williams wrote:
>> On 9/17/2014 2:18 PM, Alia Atlas wrote:
...
>>> Secondly, I am not fond of the term "Opportunistic Securi= ty" as compared
>>> to "Opportunistic Encryption" if encryption is reall= y all that is meant.
...
> The other reason to not use OE is that "encrypti= on" doesn't denote as
> much as "security".=C2=A0 In particular it doesn't denot= e "authentication",


In this opportunistic context, any use of authentication is solely i= n
the service of a better encryption mechanism.=C2=A0 In this context,
authentication has no life on its own.

For all of the many concerns expressed about the writing of the current
draft, this one point is nonetheless entirely clear.

Challenges to the use of 'opportunistic security' continue to be ra= ised
by one person after another, because it's a terrible choice.=C2=A0 This= ought
to give pause to anyone claiming that the choice of term has been
'settled'...

I am not going to comm= ent further on the selection of the term, whether
opportunistic s= ecurity or opportunistic encryption. =C2=A0My concern that=C2=A0
= opportunistic security implied more than opportunistic encryption was
=
answered by Stephen's comment that additional types of security pr= otection
(e.g. replay) could also be opportunistically offered de= pending upon the protocol
and be included in the ideas in this dr= aft.

Alia

=C2=A0
d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


--089e016355d84c243005036c2496-- From nobody Fri Sep 19 07:50:31 2014 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 8D3391A01C6; Fri, 19 Sep 2014 07:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PV5Xk6x53Egz; Fri, 19 Sep 2014 07:50:25 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5821A01C3; Fri, 19 Sep 2014 07:50:25 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8JEoKCr006172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 07:50:24 -0700 Message-ID: <541C42A5.1040302@dcrocker.net> Date: Fri, 19 Sep 2014 07:50:13 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <20140918193413.GF4071@localhost> <541C3F61.4090600@bbiw.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Sep 2014 07:50:24 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/4idX6IqNVnl4rxZcKROPi5doRMg Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 14:50:26 -0000 On 9/19/2014 7:44 AM, Alia Atlas wrote: > My concern that > opportunistic security implied more than opportunistic encryption was > answered by Stephen's comment that additional types of security protection > (e.g. replay) could also be opportunistically offered depending upon the > protocol > and be included in the ideas in this draft. Except that the existing draft solely discusses encryption (and authentication in the service of encryption.) Other possible 'opportunistic' activities might be quite reasonable, but have nothing to do with the substance of this draft. One of the continuing challenges in discussing the draft has been distinguishing what it actually says, from all sorts of appealing but abstract theories about what the term might refer to. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 19 08:20:25 2014 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 4A56C1A00F5; Fri, 19 Sep 2014 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 5WlMVvwKzv77; Fri, 19 Sep 2014 08:19:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 708511A0009; Fri, 19 Sep 2014 08:19:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 67A28BED4; Fri, 19 Sep 2014 16:19:54 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKIjq2U3ZVFy; Fri, 19 Sep 2014 16:19:54 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3E161BEBF; Fri, 19 Sep 2014 16:19:54 +0100 (IST) Message-ID: <541C499B.8060206@cs.tcd.ie> Date: Fri, 19 Sep 2014 16:19:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: dcrocker@bbiw.net, Alia Atlas References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <20140918193413.GF4071@localhost> <541C3F61.4090600@bbiw.net> <541C42A5.1040302@dcrocker.net> In-Reply-To: <541C42A5.1040302@dcrocker.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HzhtlSmLxTAZy6gwnuVeee4f4Rs Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) 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, 19 Sep 2014 15:20:06 -0000 Dave, On 19/09/14 15:50, Dave Crocker wrote: > On 9/19/2014 7:44 AM, Alia Atlas wrote: >> My concern that >> opportunistic security implied more than opportunistic encryption was >> answered by Stephen's comment that additional types of security protection >> (e.g. replay) could also be opportunistically offered depending upon the >> protocol >> and be included in the ideas in this draft. > > > Except that the existing draft solely discusses encryption (and > authentication in the service of encryption.) > > Other possible 'opportunistic' activities might be quite reasonable, but > have nothing to do with the substance of this draft. > > One of the continuing challenges in discussing the draft has been > distinguishing what it actually says, from all sorts of appealing but > abstract theories about what the term might refer to. Sigh. Aside from prolonging a discussion where both Barry and I have asked you to stop and accept the rough consensus and your bad grace bordering IMO on disruptiveness in continually not accepting that... you are also just plain wrong above. Use of authenticated encryption with additional data (AEAD) with unauthenticated endpoints does provide some replay protection in some cases. That's a property of the way AEAD ciphers work and absolutely not abstract since use of such ciphers is something that would be expected to be a common enough outcome for protocols following the OS design pattern. (The use of AEAD ciphers was already discussed as part of exactly this terminology debate though the replay protection aspect had not been mentioned which is why I brought that up in response to Alia's comment.) For background reading on AEAD [1] is a good place to start. The replay protection aspect would (as I said) depend on the details of how the protocol following the OS design pattern handled the nonces/counters needed by the AEAD cipher but in case you're wondering, if some part of the additional data is maintained in local state (e.g. a packet reception counter) then replayed ciphertext will fail decryption. In a real protocol it'd be a bit more complex, depending on what happens at reboot time and whether there are ways to resync local state between encryptor and decryptor. And none of that detail is needed or should be stated in this draft of course and if someone wants to further discuss how OS and replay protection interact, please start a new thread on the saag list since that level of (interesting) detail is not needed for the discussion of this draft. Now can we (actually, you Dave;-) stop this distraction and allow us to move on? Thanks, S. [1] https://tools.ietf.org/html/rfc5116 > > d/ > From nobody Fri Sep 19 08:42:23 2014 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 79E0B1A0104; Fri, 19 Sep 2014 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 tukN-4Cipx7h; Fri, 19 Sep 2014 08:42:17 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8778F1A00F5; Fri, 19 Sep 2014 08:42:17 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 751BD1B855D; Fri, 19 Sep 2014 08:42:16 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2F57353E074; Fri, 19 Sep 2014 08:42:16 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Sep 2014 08:42:16 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20140919142724.GZ26920@mournblade.imrryr.org> Date: Fri, 19 Sep 2014 11:41:59 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140919142724.GZ26920@mournblade.imrryr.org> To: , X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0yoJBBMqIzsPFMJE0LDzJPQG6P0 Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 19 Sep 2014 15:42:18 -0000 I think possibly what is missing is simply a clear explanation, probably = accompanied by an example or two, of what you mean by "local policy." = I would never normally think of using an https URI as relating to "local = policy," although when I read the document I did get a reasonably clear = impression that that was how you were using the term. I think you = might want to just use a different term than "local policy." E.g., = "service provider policy." I think you are trying to avoid opening the = can of worms of talking about peer vs. server vs. client, and I = understand why you want to avoid opening it, but I think in doing so you = are making the document less clear. From nobody Fri Sep 19 09:10:31 2014 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 58B441A02C1; Fri, 19 Sep 2014 09:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Id3mbDabrRoL; Fri, 19 Sep 2014 09:10:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4981A01CA; Fri, 19 Sep 2014 09:10:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E7302AAD6B; Fri, 19 Sep 2014 16:10:20 +0000 (UTC) Date: Fri, 19 Sep 2014 16:10:20 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140919161019.GF26920@mournblade.imrryr.org> References: <20140919142724.GZ26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nxP2Nc15luoD3v8o9-5lOc1855s Cc: iesg@ietf.org Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org, iesg@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:10:27 -0000 On Fri, Sep 19, 2014 at 11:41:59AM -0400, Ted Lemon wrote: > I think possibly what is missing is simply a clear explanation, probably > accompanied by an example or two, of what you mean by "local policy." > I would never normally think of using an https URI as relating to "local > policy," although when I read the document I did get a reasonably clear > impression that that was how you were using the term. Correct, the intention was to sweep all the various flavours of a-priori security requirements under the "local policy" rug. > I think you might > want to just use a different term than "local policy." E.g., "service > provider policy." I think you are trying to avoid opening the can of > worms of talking about peer vs. server vs. client, and I understand why > you want to avoid opening it, but I think in doing so you are making the > document less clear. Thanks. I'll endeavour to make this clear in -05. One option is to define something along the lines of "explicit policy" (local or otherwise). When accessing a resource or communicating with a peer for which explicit policy sets requirements for either encryption, authentication or both, then OS cannot preempt such policy to accept less secure communication, but might achieve more when consistent with that policy. I will discuss this with Pete Resnick, who's kindly volunteered to help with -05. Will try to more clearly cover both operator per-destination local policy and policy embedded in resource identifiers, whether specified locally, or obtained in the course of interaction with some peer. You're right, I don't want to take a deep dive into this tangent, ideally we'll be able to adequately communicate the idea without too much new verbiage. -- Viktor. From nobody Fri Sep 19 09:23:15 2014 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 238FC1A02BD; Fri, 19 Sep 2014 09:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 RTVdV3t90t_C; Fri, 19 Sep 2014 09:23:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A491A0063; Fri, 19 Sep 2014 09:23:07 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s8JGMvgw010169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 09:23:00 -0700 Message-ID: <541C5859.90501@dcrocker.net> Date: Fri, 19 Sep 2014 09:22:49 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , Alia Atlas References: <20140917211840.17140.26742.idtracker@ietfa.amsl.com> <541B0669.1090304@isi.edu> <20140918193413.GF4071@localhost> <541C3F61.4090600@bbiw.net> <541C42A5.1040302@dcrocker.net> <541C499B.8060206@cs.tcd.ie> In-Reply-To: <541C499B.8060206@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 19 Sep 2014 09:23:01 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/shhqLEtnu1FyF9oWApav7BSnkbs Cc: saag@ietf.org, draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:23:09 -0000 On 9/19/2014 8:19 AM, Stephen Farrell wrote: > On 19/09/14 15:50, Dave Crocker wrote: >> Except that the existing draft solely discusses encryption (and >> authentication in the service of encryption.) >> >> Other possible 'opportunistic' activities might be quite reasonable, but >> have nothing to do with the substance of this draft. >> >> One of the continuing challenges in discussing the draft has been >> distinguishing what it actually says, from all sorts of appealing but >> abstract theories about what the term might refer to. > > . you are also just plain wrong above. > > Use of authenticated encryption with additional data (AEAD) with > unauthenticated endpoints does provide some replay protection > in some cases. This is a really excellent example of just how muddled discussion of the draft has been. Thanks for demonstrating it so well. The string 'replay' does not appear in the draft. As I said, the broader implications of the term could be reasonable, but they have nothing to do with the substance of the draft. The draft is about encryption. Period. Full stop. Hence the broader term confuses the focus and utility of the draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 19 11:00:14 2014 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 1B3E31A0712; Fri, 19 Sep 2014 11:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 fYP1GfBwFH9O; Fri, 19 Sep 2014 11:00:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BE161A06F9; Fri, 19 Sep 2014 10:59:52 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s8JHxc9R006529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Sep 2014 10:59:38 -0700 (PDT) Message-ID: <541C6F0A.2010000@isi.edu> Date: Fri, 19 Sep 2014 10:59:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Ted Lemon , Nico Williams References: <20140918102937.7110.70861.idtracker@ietfa.amsl.com> <541B08A6.1080005@isi.edu> <20140918194102.GH4071@localhost> <541B386C.6050501@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mnb-vjJYbqvzYHoZmdRZ89D5WmQ Cc: "saag@ietf.org" , draft-dukhovni-opportunistic-security@tools.ietf.org, The IESG Subject: Re: [saag] Ted Lemon's Discuss on draft-dukhovni-opportunistic-security-04: (with DISCUSS and COMMENT) 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, 19 Sep 2014 18:00:09 -0000 On 9/19/2014 3:20 AM, Ted Lemon wrote: > On Sep 18, 2014, at 4:05 PM, Nico Williams wrote: >> Yes, of course, local policy (and, of course, application protocol >> specs) set a minimum. OS can only raise that minimum, not lower it. >> The I-D does say this. > > There is text in the document that talks about local policy. There > is absolutely no chance that a non-security-expert reading that would > take it to mean what I said. ... > I don't think the authors of this document want to get rid of > https://. I just think that the document needs to be clearer about that. AFAICT, this can be addressed in the pending revision. It's one of many places where the doc could be more clear, even if technically it addresses the point raised. Joe From nobody Mon Sep 22 20:33:02 2014 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 B397E1A19F6 for ; Mon, 22 Sep 2014 20:33:00 -0700 (PDT) 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_50=0.8, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 naiVLVidh7ox for ; Mon, 22 Sep 2014 20:32:55 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC881A19F4 for ; Mon, 22 Sep 2014 20:32:55 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8N3WrrB002563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Sep 2014 03:32:54 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8N3Wr0r020503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2014 03:32:53 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8N3WrdC009914; Tue, 23 Sep 2014 03:32:53 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Sep 2014 20:32:52 -0700 Date: Mon, 22 Sep 2014 20:32:50 -0700 (PDT) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Petr Spacek In-Reply-To: Message-ID: References: <20140721175658.1086.20555.idtracker@ietfa.amsl.com> <53D25A83.2020607@redhat.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-947435663-1411443172=:14810" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/N9gXUJpnv3KbSJpOC-HS0SX9hbQ Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] nitpicks about draft-pechanec-pkcs11uri-14.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: Tue, 23 Sep 2014 03:33:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-947435663-1411443172=:14810 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Jul 2014, Jan Pechanec wrote: >On Fri, 25 Jul 2014, Petr Spacek wrote: > >> Hello, > > hi Petr, > >> I'm implementing draft-pechanec-pkcs11uri-14 for FreeIPA project and during >> that work I have found two nits on draft-pechanec-pkcs11uri-14: >> >> On http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14#page-6: >> >> I would propose to split/reformulate the paragraph starting with: >> "The path component attribute "token" represents a token label and corresponds >> to the "label" member of the CK_TOKEN_INFO structure" ... >> >> The first sentence (enumeration) spans over 15 lines and I personally find it >> difficult to read. Maybe a table would be better: ><...> > > thanks for the feedback, it's much appreciated. I will see what >I can do about this one. hello Petr, attached is a new working version of the draft, I plan to file it within a few days. Does it address your comment? Aside from the change that converted that long paragraph into a table, there are also a couple of minor clarification changes unrelated to your feedback. thanks, Jan. -- Jan Pechanec ---559023410-947435663-1411443172=:14810 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=draft-pechanec-pkcs11uri-15.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=draft-pechanec-pkcs11uri-15.txt DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSi4gUGVjaGFuZWMNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1vZmZhdA0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFy ZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgT3JhY2xlIENvcnBvcmF0 aW9uDQpFeHBpcmVzOiBNYXJjaCAyNiwgMjAxNSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMjIsIDIwMTQNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZQ0KICAg ICAgICAgICAgICAgICAgICAgIGRyYWZ0LXBlY2hhbmVjLXBrY3MxMXVyaS0x NQ0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gc3BlY2lmaWVzIGEgUEtD UyMxMSBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkNCiAgIFNj aGVtZSBmb3IgaWRlbnRpZnlpbmcgUEtDUyMxMSBvYmplY3RzIHN0b3JlZCBp biBQS0NTIzExIHRva2VucywgZm9yDQogICBpZGVudGlmeWluZyBQS0NTIzEx IHRva2VucyB0aGVtc2VsdmVzLCBvciBmb3IgaWRlbnRpZnlpbmcgUEtDUyMx MQ0KICAgbGlicmFyaWVzLiAgVGhlIFVSSSBpcyBiYXNlZCBvbiBob3cgUEtD UyMxMSBvYmplY3RzLCB0b2tlbnMsIGFuZA0KICAgbGlicmFyaWVzIGFyZSBp ZGVudGlmaWVkIGluIHRoZSBQS0NTIzExIENyeXB0b2dyYXBoaWMgVG9rZW4g SW50ZXJmYWNlDQogICBTdGFuZGFyZC4NCg0KU3RhdHVzIG9mIFRoaXMgTWVt bw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBm dWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJD UCA3OCBhbmQgQkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0K ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtDQogICBEcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBv YnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBh cyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhl ciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhpcyBJbnRl cm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXJjaCAyNiwgMjAxNS4NCg0K Q29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKGMpIDIwMTQgSUVU RiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBhcyB0aGUNCiAg IGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLg0KDQog ICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUg SUVURiBUcnVzdCdzIExlZ2FsDQogICBQcm92aXNpb25zIFJlbGF0aW5nIHRv IElFVEYgRG9jdW1lbnRzDQogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YNCiAgIHB1 YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRo ZXNlIGRvY3VtZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJl IHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQog ICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3Rl ZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdA0KICAgaW5jbHVkZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g NC5lIG9mDQoNCg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICBFeHBp cmVzIE1hcmNoIDI2LCAyMDE1ICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBT Y2hlbWUgICAgICAgICAgIFNlcHRlbWJlciAyMDE0DQoNCg0KICAgdGhlIFRy dXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0 IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJ bnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgMg0KICAgMi4gIENvbnRyaWJ1dG9ycyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g ICAzDQogICAzLiAgUEtDUyMxMSBVUkkgU2NoZW1lIERlZmluaXRpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMNCiAgICAgMy4xLiAg UEtDUyMxMSBVUkkgU2NoZW1lIE5hbWUgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAgNA0KICAgICAzLjIuICBQS0NTIzExIFVSSSBTY2hl bWUgU3RhdHVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0 DQogICAgIDMuMy4gIFBLQ1MjMTEgVVJJIFNjaGVtZSBTeW50YXggLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQNCiAgICAgMy40LiAgUEtD UyMxMSBVUkkgU2NoZW1lIFF1ZXJ5IEF0dHJpYnV0ZSBTZW1hbnRpY3MgIC4g LiAuIC4gLiAuICAgOA0KICAgICAzLjUuICBQS0NTIzExIFVSSSBNYXRjaGlu ZyBHdWlkZWxpbmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEwDQog ICAgIDMuNi4gIFBLQ1MjMTEgVVJJIENvbXBhcmlzb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTENCiAgIDQuICBFeGFtcGxlcyBv ZiBQS0NTIzExIFVSSXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMg0KICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1DQogICA2 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUNCiAgIDcuICBSZWZlcmVuY2VzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxNQ0KICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1DQogICAgIDcu Mi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTYNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoZSBQS0NTICMxMTog Q3J5cHRvZ3JhcGhpYyBUb2tlbiBJbnRlcmZhY2UgU3RhbmRhcmQgW3BrY3Mx MV9zcGVjXQ0KICAgc3BlY2lmaWVzIGFuIEFQSSwgY2FsbGVkIENyeXB0b2tp LCBmb3IgZGV2aWNlcyB3aGljaCBob2xkDQogICBjcnlwdG9ncmFwaGljIGlu Zm9ybWF0aW9uIGFuZCBwZXJmb3JtIGNyeXB0b2dyYXBoaWMgZnVuY3Rpb25z Lg0KICAgQ3J5cHRva2ksIHByb25vdW5jZWQgY3J5cHRvLWtleSBhbmQgc2hv cnQgZm9yIGNyeXB0b2dyYXBoaWMgdG9rZW4NCiAgIGludGVyZmFjZSwgZm9s bG93cyBhIHNpbXBsZSBvYmplY3QtYmFzZWQgYXBwcm9hY2gsIGFkZHJlc3Np bmcgdGhlDQogICBnb2FscyBvZiB0ZWNobm9sb2d5IGluZGVwZW5kZW5jZSAo YW55IGtpbmQgb2YgZGV2aWNlIG1heSBiZSB1c2VkKSBhbmQNCiAgIHJlc291 cmNlIHNoYXJpbmcgKG11bHRpcGxlIGFwcGxpY2F0aW9ucyBtYXkgYWNjZXNz IG11bHRpcGxlIGRldmljZXMpLA0KICAgcHJlc2VudGluZyBhcHBsaWNhdGlv bnMgd2l0aCBhIGNvbW1vbiwgbG9naWNhbCB2aWV3IG9mIHRoZSBkZXZpY2Ug LSBhDQogICBjcnlwdG9ncmFwaGljIHRva2VuLg0KDQogICBJdCBpcyBkZXNp cmFibGUgZm9yIGFwcGxpY2F0aW9ucyBvciBsaWJyYXJpZXMgdGhhdCB3b3Jr IHdpdGggUEtDUyMxMQ0KICAgdG9rZW5zIHRvIGFjY2VwdCBhIGNvbW1vbiBp ZGVudGlmaWVyIHRoYXQgY29uc3VtZXJzIGNvdWxkIHVzZSB0bw0KICAgaWRl bnRpZnkgYW4gZXhpc3RpbmcgUEtDUyMxMSBzdG9yYWdlIG9iamVjdCBpbiBh IFBLQ1MjMTEgdG9rZW4sIGFuDQogICBleGlzdGluZyB0b2tlbiBpdHNlbGYs IG9yIGFuIGV4aXN0aW5nIENyeXB0b2tpIGxpYnJhcnkgKGFsc28gY2FsbGVk IGENCiAgIHByb2R1Y2VyLCBtb2R1bGUsIG9yIHByb3ZpZGVyKS4gIFRoZSBz ZXQgb2Ygc3RvcmFnZSBvYmplY3QgdHlwZXMgdGhhdA0KICAgY2FuIGJlIHN0 b3JlZCBpbiBhIFBLQ1MjMTEgdG9rZW4gaW5jbHVkZXMgYSBjZXJ0aWZpY2F0 ZSwgYSBwdWJsaWMsDQogICBwcml2YXRlIG9yIHNlY3JldCBrZXksIGFuZCBh IGRhdGEgb2JqZWN0LiAgVGhlc2Ugb2JqZWN0cyBjYW4gYmUNCiAgIHVuaXF1 ZWx5IGlkZW50aWZpYWJsZSB2aWEgdGhlIFBLQ1MjMTEgVVJJIHNjaGVtZSBk ZWZpbmVkIGluIHRoaXMNCiAgIGRvY3VtZW50LiAgVGhlIHNldCBvZiBhdHRy aWJ1dGVzIGRlc2NyaWJpbmcgYSBzdG9yYWdlIG9iamVjdCBjYW4NCiAgIGNv bnRhaW4gYW4gb2JqZWN0IGxhYmVsLCBpdHMgdHlwZSwgYW5kIGl0cyBJRC4g IFRoZSBzZXQgb2YgYXR0cmlidXRlcw0KICAgdGhhdCBpZGVudGlmaWVzIGEg UEtDUyMxMSB0b2tlbiBjYW4gY29udGFpbiBhIHRva2VuIGxhYmVsLCBhDQog ICBtYW51ZmFjdHVyZXIgbmFtZSwgYSBzZXJpYWwgbnVtYmVyLCBhbmQgYSB0 b2tlbiBtb2RlbC4gIEF0dHJpYnV0ZXMNCiAgIHRoYXQgY2FuIGlkZW50aWZ5 IGEgQ3J5cHRva2kgbGlicmFyeSBhcmUgYSBsaWJyYXJ5IG1hbnVmYWN0dXJl ciwgYQ0KICAgbGlicmFyeSBkZXNjcmlwdGlvbiwgYW5kIGEgbGlicmFyeSB2 ZXJzaW9uLiAgTGlicmFyeSBhdHRyaWJ1dGVzIG1heQ0KDQoNCg0KUGVjaGFu ZWMgJiBNb2ZmYXQgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMTUgICAg ICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgU2VwdGVt YmVyIDIwMTQNCg0KDQogICBiZSBuZWNlc3NhcnkgdG8gdXNlIGlmIG1vcmUg dGhhbiBvbmUgQ3J5cHRva2kgbGlicmFyeSBwcm92aWRlcyBhDQogICB0b2tl biBhbmQvb3IgUEtDUyMxMSBvYmplY3RzIG9mIHRoZSBzYW1lIG5hbWUocyku ICBBIHNldCBvZiBxdWVyeQ0KICAgYXR0cmlidXRlcyBpcyBwcm92aWRlZCBh cyB3ZWxsLg0KDQogICBUaGUgUEtDUyMxMSBVUkkgY2Fubm90IGlkZW50aWZ5 IG90aGVyIG9iamVjdHMgZGVmaW5lZCBpbiB0aGUNCiAgIHNwZWNpZmljYXRp b24gW3BrY3MxMV9zcGVjXSBhc2lkZSBmcm9tIHN0b3JhZ2Ugb2JqZWN0cy4g IEZvciBleGFtcGxlLA0KICAgb2JqZWN0cyBub3QgaWRlbnRpZmlhYmxlIGJ5 IGEgUEtDUyMxMSBVUkkgaW5jbHVkZSBhIGhhcmR3YXJlIGZlYXR1cmUNCiAg IGFuZCBtZWNoYW5pc20uICBOb3RlIHRoYXQgYSBDcnlwdG9raSBsaWJyYXJ5 IGRvZXMgbm90IGhhdmUgdG8gcHJvdmlkZQ0KICAgZm9yIHN0b3JhZ2Ugb2Jq ZWN0cyBhdCBhbGwuICBUaGUgVVJJIGNhbiBzdGlsbCBiZSB1c2VkIHRvIGlk ZW50aWZ5IGENCiAgIHNwZWNpZmljIFBLQ1MjMTEgdG9rZW4gb3IgYW4gQVBJ IHByb2R1Y2VyIGluIHN1Y2ggYSBjYXNlLg0KDQogICBBIHN1YnNldCBvZiBl eGlzdGluZyBQS0NTIzExIHN0cnVjdHVyZSBtZW1iZXJzIGFuZCBvYmplY3Qg YXR0cmlidXRlcw0KICAgd2FzIGNob3NlbiBiZWxpZXZlZCB0byBiZSBzdWZm aWNpZW50IGluIHVuaXF1ZWx5IGlkZW50aWZ5aW5nIGENCiAgIFBLQ1MjMTEg dG9rZW4sIHN0b3JhZ2Ugb2JqZWN0LCBvciBsaWJyYXJ5IGluIGEgY29uZmln dXJhdGlvbiBmaWxlLCBvbg0KICAgYSBjb21tYW5kIGxpbmUsIG9yIGluIGEg Y29uZmlndXJhdGlvbiBwcm9wZXJ0eSBvZiBzb21ldGhpbmcgZWxzZS4NCiAg IFNob3VsZCB0aGVyZSBiZSBhIG5lZWQgZm9yIGEgbW9yZSBjb21wbGV4IGlu Zm9ybWF0aW9uIGV4Y2hhbmdlIG9uDQogICBQS0NTIzExIGVudGl0aWVzIGEg ZGlmZmVyZW50IG1lYW5zIG9mIGRhdGEgbWFyc2hhbGxpbmcgc2hvdWxkIGJl DQogICBjaG9zZW4gYWNjb3JkaW5nbHkuDQoNCiAgIEEgUEtDUyMxMSBVUkkg aXMgbm90IGludGVuZGVkIHRvIGJlIHVzZWQgdG8gY3JlYXRlIG5ldyBQS0NT IzExDQogICBvYmplY3RzIGluIHRva2Vucywgb3IgdG8gY3JlYXRlIFBLQ1Mj MTEgdG9rZW5zLiAgSXQgaXMgc29sZWx5IHRvIGJlDQogICB1c2VkIHRvIGlk ZW50aWZ5IGFuZCB3b3JrIHdpdGggZXhpc3Rpbmcgc3RvcmFnZSBvYmplY3Rz IGFuZCB0b2tlbnMNCiAgIHRocm91Z2ggdGhlIFBLQ1MjMTEgQVBJLCBvciBp ZGVudGlmeSBDcnlwdG9raSBsaWJyYXJpZXMgdGhlbXNlbHZlcy4NCg0KICAg VGhlIFVSSSBzY2hlbWUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGlzIGRl c2lnbmVkIHNwZWNpZmljYWxseSB3aXRoDQogICBhIG1hcHBpbmcgdG8gdGhl IFBLQ1MjMTEgQVBJIGluIG1pbmQuICBUaGUgVVJJIHVzZXMgdGhlIHNjaGVt ZSwgcGF0aA0KICAgYW5kIHF1ZXJ5IGNvbXBvbmVudHMgZGVmaW5lZCBpbiB0 aGUgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyDQogICAoVVJJKTogR2Vu ZXJpYyBTeW50YXggW1JGQzM5ODZdIGRvY3VtZW50LiAgVGhlIFVSSSBkb2Vz IG5vdCB1c2UgdGhlDQogICBoaWVyYXJjaGljYWwgZWxlbWVudCBmb3IgYSBu YW1pbmcgYXV0aG9yaXR5IGluIHRoZSBwYXRoIHNpbmNlIHRoZQ0KICAgYXV0 aG9yaXR5IHBhcnQgY291bGQgbm90IGJlIG1hcHBlZCB0byBQS0NTIzExIEFQ SSBlbGVtZW50cy4gIFRoZSBVUkkNCiAgIGRvZXMgbm90IHVzZSB0aGUgZnJh Z21lbnQgY29tcG9uZW50Lg0KDQogICBJZiBhbiBhcHBsaWNhdGlvbiBoYXMg bm8gYWNjZXNzIHRvIGEgcHJvZHVjZXIgb3IgcHJvZHVjZXJzIG9mIHRoZQ0K ICAgUEtDUyMxMSBBUEkgdGhlIHF1ZXJ5IGNvbXBvbmVudCBtb2R1bGUgYXR0 cmlidXRlcyBjYW4gYmUgdXNlZC4NCiAgIEhvd2V2ZXIsIHRoZSBQS0NTIzEx IFVSSSBjb25zdW1lciBjYW4gYWx3YXlzIGRlY2lkZSB0byBwcm92aWRlIGl0 cw0KICAgb3duIGFkZXF1YXRlIHVzZXIgaW50ZXJmYWNlIHRvIGxvY2F0ZSBh bmQgbG9hZCBQS0NTIzExIEFQSQ0KICAgcHJvZHVjZXIocykuDQoNCjIuICBD b250cmlidXRvcnMNCg0KICAgU3RlZiBXYWx0ZXIsIE5pa29zIE1hdnJvZ2lh bm5vcG91bG9zLCBOaWNvIFdpbGxpYW1zLCBEYW4gV2luc2hpcCwgYW5kDQog ICBKYXJvc2xhdiBJbXJpY2ggY29udHJpYnV0ZWQgdG8gdGhlIGRldmVsb3Bt ZW50IG9mIHRoaXMgZG9jdW1lbnQuDQoNCjMuICBQS0NTIzExIFVSSSBTY2hl bWUgRGVmaW5pdGlvbg0KDQogICBJbiBhY2NvcmRhbmNlIHdpdGggW1JGQzQz OTVdLCB0aGlzIHNlY3Rpb24gcHJvdmlkZXMgdGhlIGluZm9ybWF0aW9uDQog ICByZXF1aXJlZCB0byByZWdpc3RlciB0aGUgUEtDUyMxMSBVUkkgc2NoZW1l Lg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgRXhwaXJlcyBN YXJjaCAyNiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1l ICAgICAgICAgICBTZXB0ZW1iZXIgMjAxNA0KDQoNCjMuMS4gIFBLQ1MjMTEg VVJJIFNjaGVtZSBOYW1lDQoNCiAgIHBrY3MxMQ0KDQozLjIuICBQS0NTIzEx IFVSSSBTY2hlbWUgU3RhdHVzDQoNCiAgIFBlcm1hbmVudC4NCg0KMy4zLiAg UEtDUyMxMSBVUkkgU2NoZW1lIFN5bnRheA0KDQogICBUaGUgUEtDUyMxMSBV UkkgaXMgYSBzZXF1ZW5jZSBvZiBhdHRyaWJ1dGUgdmFsdWUgcGFpcnMgc2Vw YXJhdGVkIGJ5IGENCiAgIHNlbWljb2xvbiB0aGF0IGZvcm0gYSBvbmUgbGV2 ZWwgcGF0aCBjb21wb25lbnQsIG9wdGlvbmFsbHkgZm9sbG93ZWQNCiAgIGJ5 IGEgcXVlcnkuICBJbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiAyLjUgb2Yg W1JGQzM5ODZdLCB0aGUgZGF0YQ0KICAgc2hvdWxkIGZpcnN0IGJlIGVuY29k ZWQgYXMgb2N0ZXRzIGFjY29yZGluZyB0byB0aGUgVVRGLTggY2hhcmFjdGVy DQogICBlbmNvZGluZyBbUkZDMzYyOV07IHRoZW4gb25seSB0aG9zZSBvY3Rl dHMgdGhhdCBkbyBub3QgY29ycmVzcG9uZCB0bw0KICAgY2hhcmFjdGVycyBp biB0aGUgdW5yZXNlcnZlZCBzZXQgb3IgdG8gcGVybWl0dGVkIGNoYXJhY3Rl cnMgZnJvbSB0aGUNCiAgIHJlc2VydmVkIHNldCBzaG91bGQgYmUgcGVyY2Vu dC1lbmNvZGVkLiAgVGhpcyBzcGVjaWZpY2F0aW9uIHN1Z2dlc3RzDQogICBv bmUgYWxsb3dhYmxlIGV4Y2VwdGlvbiB0byB0aGF0IHJ1bGUgZm9yIHRoZSAi aWQiIGF0dHJpYnV0ZSwgYXMNCiAgIHN0YXRlZCBsYXRlciBpbiB0aGlzIHNl Y3Rpb24uICBHcmFtbWFyIHJ1bGVzICJ1bnJlc2VydmVkIiBhbmQgInBjdC0N CiAgIGVuY29kZWQiIGluIHRoZSBQS0NTIzExIFVSSSBzcGVjaWZpY2F0aW9u IGJlbG93IGFyZSBpbXBvcnRlZCBmcm9tDQogICBbUkZDMzk4Nl0uICBBcyBh IHNwZWNpYWwgY2FzZSwgbm90ZSB0aGF0IGFjY29yZGluZyB0byBBcHBlbmRp eCBBIG9mDQogICBbUkZDMzk4Nl0sIGEgc3BhY2UgbXVzdCBiZSBwZXJjZW50 LWVuY29kZWQuDQoNCiAgIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBpbXBvc2Vz IHZhcmlvdXMgbGltaXRhdGlvbnMgb24gdGhlIHZhbHVlIG9mDQogICBhdHRy aWJ1dGVzLCBiZSBpdCBhIG1vcmUgcmVzdHJpY3RpdmUgY2hhcmFjdGVyIHNl dCBmb3IgdGhlICJzZXJpYWwiDQogICBhdHRyaWJ1dGUgb3IgZml4ZWQgc2l6 ZWQgYnVmZmVycyBmb3IgYWxtb3N0IGFsbCB0aGUgb3RoZXJzLCBpbmNsdWRp bmcNCiAgICJ0b2tlbiIsICJtYW51ZmFjdHVyZXIiLCBhbmQgIm1vZGVsIiBh dHRyaWJ1dGVzLiAgSG93ZXZlciwgdGhlDQogICBQS0NTIzExIFVSSSBub3Rh dGlvbiBkb2VzIG5vdCBpbXBvc2Ugc3VjaCBsaW1pdGF0aW9ucyBhc2lkZSBm cm9tDQogICByZW1vdmluZyBnZW5lcmljIGFuZCBQS0NTIzExIFVSSSBkZWxp bWl0ZXJzIGZyb20gYSBwZXJtaXR0ZWQNCiAgIGNoYXJhY3RlciBzZXQuICBX ZSBiZWxpZXZlIHRoYXQgYmVpbmcgdG9vIHJlc3RyaWN0aXZlIG9uIHRoZQ0K ICAgYXR0cmlidXRlIHZhbHVlcyBjb3VsZCBsaW1pdCB0aGUgUEtDUyMxMSBV UkkncyB1c2VmdWxuZXNzLiAgV2hhdCBpcw0KICAgbW9yZSwgcG9zc2libGUg ZnV0dXJlIGNoYW5nZXMgdG8gdGhlIFBLQ1MjMTEgc3BlY2lmaWNhdGlvbiBz aG91bGQgbm90DQogICBhZmZlY3QgZXhpc3RpbmcgYXR0cmlidXRlcy4NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBlY2hhbmVjICYg TW9mZmF0ICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAyMDE1ICAgICAgICAg ICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg IFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAgIFNlcHRlbWJlciAy MDE0DQoNCg0KICAgQSBQS0NTIzExIFVSSSB0YWtlcyB0aGUgZm9ybSAoZm9y IGV4cGxhbmF0aW9uIG9mIEF1Z21lbnRlZCBCTkYsIHNlZQ0KICAgW1JGQzUy MzRdKToNCg0KICBwazExLVVSSSAgICAgICAgICAgICA9ICJwa2NzMTEiICI6 IiBwazExLXBhdGggKjEoIj8iIHBrMTEtcXVlcnkpDQogIDsgUGF0aCBjb21w b25lbnQgYW5kIGl0cyBhdHRyaWJ1dGVzLiAgUGF0aCBtYXkgYmUgZW1wdHku DQogIHBrMTEtcGF0aCAgICAgICAgICAgID0gKjEocGsxMS1wYXR0ciAqKCI7 IiBwazExLXBhdHRyKSkNCiAgcGsxMS1wYXR0ciAgICAgICAgICAgPSBwazEx LXRva2VuIC8gcGsxMS1tYW51ZiAvIHBrMTEtc2VyaWFsIC8NCiAgICAgICAg ICAgICAgICAgICAgICAgICBwazExLW1vZGVsIC8gcGsxMS1saWItbWFudWYg Lw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBrMTEtbGliLXZlciAvIHBr MTEtbGliLWRlc2MgLw0KICAgICAgICAgICAgICAgICAgICAgICAgIHBrMTEt b2JqZWN0IC8gcGsxMS10eXBlIC8gcGsxMS1pZCAvDQogICAgICAgICAgICAg ICAgICAgICAgICAgcGsxMS14LXBhdHRyDQogIDsgUXVlcnkgY29tcG9uZW50 IGFuZCBpdHMgYXR0cmlidXRlcy4gIFF1ZXJ5IG1heSBiZSBlbXB0eS4NCiAg cGsxMS1xYXR0ciAgICAgICAgICAgPSBwazExLXBpbi1zb3VyY2UgLyBwazEx LXBpbi12YWx1ZSAvDQogICAgICAgICAgICAgICAgICAgICAgICAgcGsxMS1t b2R1bGUtbmFtZSAvIHBrMTEtbW9kdWxlLXBhdGggLw0KICAgICAgICAgICAg ICAgICAgICAgICAgIHBrMTEteC1xYXR0cg0KICBwazExLXF1ZXJ5ICAgICAg ICAgICA9ICoxKHBrMTEtcWF0dHIgKigiJiIgcGsxMS1xYXR0cikpDQogIDsg UkZDIDM5ODYgc2VjdGlvbiAyLjIgbWFuZGF0ZXMgYWxsIHBvdGVudGlhbGx5 IHJlc2VydmVkIGNoYXJhY3RlcnMNCiAgOyB0aGF0IGRvIG5vdCBjb25mbGlj dCB3aXRoIGFjdHVhbCBkZWxpbWl0ZXJzIG9mIHRoZSBVUkkgZG8gbm90IGhh dmUNCiAgOyB0byBiZSBwZXJjZW50LWVuY29kZWQuDQogIHBrMTEtcmVzLWF2 YWlsICAgICAgID0gIjoiIC8gIlsiIC8gIl0iIC8gIkAiIC8gIiEiIC8gIiQi IC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAiJyIgLyAiKCIgLyAiKSIg LyAiKiIgLyAiKyIgLyAiLCIgLyAiPSINCiAgcGsxMS1wYXRoLXJlcy1hdmFp bCAgPSBwazExLXJlcy1hdmFpbCAvICImIg0KICA7IFdlIGFsbG93ICIvIiBh bmQgIj8iIGluIHRoZSBxdWVyeSB0byBiZSB1bmVuY29kZWQgYnV0ICImIiBt dXN0DQogIDsgYmUgZW5jb2RlZCBzaW5jZSBpdCBtYXkgYmUgdXNlZCBhcyBh IGRlbGltaXRlciBpbiB0aGUgY29tcG9uZW50Lg0KICBwazExLXF1ZXJ5LXJl cy1hdmFpbCA9IHBrMTEtcmVzLWF2YWlsIC8gIi8iIC8gIj8iIC8gInwiDQog IHBrMTEtcGNoYXIgICAgICAgICAgID0gdW5yZXNlcnZlZCAvIHBrMTEtcGF0 aC1yZXMtYXZhaWwgLyBwY3QtZW5jb2RlZA0KICBwazExLXFjaGFyICAgICAg ICAgICA9IHVucmVzZXJ2ZWQgLyBwazExLXF1ZXJ5LXJlcy1hdmFpbCAvIHBj dC1lbmNvZGVkDQogIHBrMTEtdG9rZW4gICAgICAgICAgID0gInRva2VuIiAi PSIgKnBrMTEtcGNoYXINCiAgcGsxMS1tYW51ZiAgICAgICAgICAgPSAibWFu dWZhY3R1cmVyIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1zZXJpYWwgICAg ICAgICAgPSAic2VyaWFsIiAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS1tb2Rl bCAgICAgICAgICAgPSAibW9kZWwiICI9IiAqcGsxMS1wY2hhcg0KICBwazEx LWxpYi1tYW51ZiAgICAgICA9ICJsaWJyYXJ5LW1hbnVmYWN0dXJlciIgIj0i ICpwazExLXBjaGFyDQogIHBrMTEtbGliLWRlc2MgICAgICAgID0gImxpYnJh cnktZGVzY3JpcHRpb24iICI9IiAqcGsxMS1wY2hhcg0KICBwazExLWxpYi12 ZXIgICAgICAgICA9ICJsaWJyYXJ5LXZlcnNpb24iICI9IiAxKkRJR0lUICox KCIuIiAxKkRJR0lUKQ0KICBwazExLW9iamVjdCAgICAgICAgICA9ICJvYmpl Y3QiICI9IiAqcGsxMS1wY2hhcg0KICBwazExLXR5cGUgICAgICAgICAgICA9 ICJ0eXBlIiAiPSIgKjEoInB1YmxpYyIgLyAicHJpdmF0ZSIgLyAiY2VydCIg Lw0KICAgICAgICAgICAgICAgICAgICAgICAgICJzZWNyZXQta2V5IiAvICJk YXRhIikNCiAgcGsxMS1pZCAgICAgICAgICAgICAgPSAiaWQiICI9IiAqcGsx MS1wY2hhcg0KICBwazExLXBpbi1zb3VyY2UgICAgICA9ICJwaW4tc291cmNl IiAiPSIgKnBrMTEtcWNoYXINCiAgcGsxMS1waW4tdmFsdWUgICAgICAgPSAi cGluLXZhbHVlIiAiPSIgKnBrMTEtcWNoYXINCiAgcGsxMS1tb2R1bGUtbmFt ZSAgICAgPSAibW9kdWxlLW5hbWUiID0gKnBrMTEtcWNoYXINCiAgcGsxMS1t b2R1bGUtcGF0aCAgICAgPSAibW9kdWxlLXBhdGgiID0gKnBrMTEtcWNoYXIN CiAgcGsxMS14LWF0dHItbm0tY2hhciAgPSBBTFBIQSAvIERJR0lUIC8gIi0i IC8gIl8iDQogIDsgUGVybWl0dGVkIHZhbHVlIG9mIGEgdmVuZG9yIHNwZWNp ZmljIGF0dHJpYnV0ZSBpcyBiYXNlZCBvbg0KICA7IHdoZXRoZXIgdGhlIGF0 dHJpYnV0ZSBpcyB1c2VkIGluIHRoZSBwYXRoIG9yIGluIHRoZSBxdWVyeS4N CiAgcGsxMS14LXBhdHRyICAgICAgICAgPSAieC0iIDEqcGsxMS14LWF0dHIt bm0tY2hhciAiPSIgKnBrMTEtcGNoYXINCiAgcGsxMS14LXFhdHRyICAgICAg ICAgPSAieC0iIDEqcGsxMS14LWF0dHItbm0tY2hhciAiPSIgKnBrMTEtcWNo YXINCg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgIEV4cGlyZXMg TWFyY2ggMjYsIDIwMTUgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVt ZSAgICAgICAgICAgU2VwdGVtYmVyIDIwMTQNCg0KDQogICBUaGUgVVJJIHBh dGggY29tcG9uZW50IGNvbnRhaW5zIGF0dHJpYnV0ZXMgdGhhdCBpZGVudGlm eSBhIHJlc291cmNlDQogICBpbiBhIG9uZSBsZXZlbCBoaWVyYXJjaHkgcHJv dmlkZWQgYnkgQ3J5cHRva2kgcHJvZHVjZXJzLiAgVGhlIHF1ZXJ5DQogICBj b21wb25lbnQgY2FuIGNvbnRhaW4gYSBmZXcgYXR0cmlidXRlcyB0aGF0IG1h eSBiZSBuZWVkZWQgdG8gcmV0cmlldmUNCiAgIHRoZSByZXNvdXJjZSBpZGVu dGlmaWVkIGJ5IHRoZSBVUkkgcGF0aC4gIEJvdGggcGF0aCBhbmQgcXVlcnkN CiAgIGNvbXBvbmVudHMgbWF5IGNvbnRhaW4gdmVuZG9yIHNwZWNpZmljIGF0 dHJpYnV0ZXMuICBTdWNoIGF0dHJpYnV0ZQ0KICAgbmFtZXMgbXVzdCBzdGFy dCB3aXRoIGFuICJ4LSIgcHJlZml4LiAgQXR0cmlidXRlcyBpbiB0aGUgcGF0 aA0KICAgY29tcG9uZW50IGFyZSBkZWxpbWl0ZWQgYnkgJzsnIGNoYXJhY3Rl ciwgYXR0cmlidXRlcyBpbiB0aGUgcXVlcnkNCiAgIGNvbXBvbmVudCB1c2Ug JyYnIGFzIGEgZGVsaW1pdGVyLg0KDQogICBUaGUgZ2VuZXJhbCAnLycgZGVs aW1pdGVyIHdhcyByZW1vdmVkIGZyb20gYXZhaWxhYmxlIGNoYXJhY3RlcnMg dGhhdA0KICAgZG8gbm90IGhhdmUgdG8gYmUgcGVyY2VudC1lbmNvZGVkIGlu IHRoZSBwYXRoIGNvbXBvbmVudCBzbyB0aGF0DQogICBnZW5lcmljIFVSSSBw YXJzZXJzIG5ldmVyIHNwbGl0IHRoZSBwYXRoIGNvbXBvbmVudCBpbnRvIG11 bHRpcGxlDQogICBzZWdtZW50cy4gIFRoZSAnLycgZGVsaW1pdGVyIGNhbiBi ZSB1c2VkIHVuZW5jb2RlZCBpbiB0aGUgcXVlcnkNCiAgIGNvbXBvbmVudC4g IERlbGltaXRlciAnPycgd2FzIHJlbW92ZWQgc2luY2UgdGhlIFBLQ1MjMTEg VVJJIHVzZXMgYQ0KICAgcXVlcnkgY29tcG9uZW50LiAgRGVsaW1pdGVyICcj JyB3YXMgcmVtb3ZlZCBzbyB0aGF0IGdlbmVyaWMgVVJJDQogICBwYXJzZXJz IGFyZSBub3QgY29uZnVzZWQgYnkgdW5lbmNvZGVkIGhhc2ggY2hhcmFjdGVy cy4gIEFsbCBvdGhlcg0KICAgZ2VuZXJpYyBkZWxpbWl0ZXJzIGFyZSBhbGxv d2VkIHRvIGJlIHVzZWQgdW5lbmNvZGVkICgnOicsICdbJywgJ10nLA0KICAg YW5kICdAJykgaW4gdGhlIFBLQ1MjMTEgVVJJLg0KDQogICBUaGUgZm9sbG93 aW5nIHRhYmxlIHByZXNlbnRzIG1hcHBpbmcgYmV0d2VlbiB0aGUgUEtDUyMx MSBVUkkgcGF0aA0KICAgY29tcG9uZW50IGF0dHJpYnV0ZXMgYW5kIHRoZSBQ S0NTIzExIEFQSSBzdHJ1Y3R1cmUgbWVtYmVycyBhbmQgb2JqZWN0DQogICBh dHRyaWJ1dGVzLiAgR2l2ZW4gdGhhdCBQS0NTIzExIFVSSSB1c2VycyBtYXkg YmUgcXVpdGUgaWdub3JhbnQgYWJvdXQNCiAgIHRoZSBQS0NTIzExIHNwZWNp ZmljYXRpb24gdGhlIG1hcHBpbmcgaXMgYSBwcm9kdWN0IG9mIGEgbmVjZXNz YXJ5DQogICBjb21wcm9taXNlIGJldHdlZW4gaG93IHByZWNpc2VseSBhcmUg dGhlIFVSSSBhdHRyaWJ1dGUgbmFtZXMgbWFwcGVkDQogICB0byB0aGUgbmFt ZXMgaW4gdGhlIHNwZWNpZmljYXRpb24gYW5kIHRoZSBlYXNlIG9mIHVzZSBh bmQNCiAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIFVSSSBzY2hlbWUuDQoNCiAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBVUkkgY29tcG9uZW50 IHBhdGggICB8IEF0dHJpYnV0ZSAgICAgICAgICAgfCBBdHRyaWJ1dGUgICAg ICAgICAgICB8DQogICB8IGF0dHJpYnV0ZSBuYW1lICAgICAgIHwgcmVwcmVz ZW50cyAgICAgICAgICB8IGNvcnJlc3BvbmRzIGluIHRoZSAgIHwNCiAgIHwg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwg UEtDUyMxMSAgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBzcGVjaWZpY2F0aW9uIHRv ICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCBpZCAgICAgICAgICAgICAgICAg ICB8IGtleSBpZGVudGlmaWVyIGZvciAgfCAiQ0tBX0lEIiBvYmplY3QgICAg ICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgb2JqZWN0ICAgICAg ICAgICAgICB8IGF0dHJpYnV0ZSAgICAgICAgICAgIHwNCiAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KICAgfCBsaWJyYXJ5LWRlc2NyaXB0aW9uICB8 IGNoYXJhY3Rlci1zdHJpbmcgICAgfCAibGlicmFyeURlc2NyaXB0aW9uIiB8 DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgZGVzY3JpcHRpb24gb2Yg dGhlICB8IG1lbWJlciBvZiBDS19JTkZPICAgIHwNCiAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCBsaWJyYXJ5ICAgICAgICAgICAgIHwgc3RydWN0dXJl ICAgICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8IGxpYnJhcnktbWFudWZhY3R1cmVyIHwgSUQgb2YgdGhlIENyeXB0b2tp ICB8ICJtYW51ZmFjdHVyZXJJRCIgICAgIHwNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCBsaWJyYXJ5ICAgICAgICAgICAgIHwgbWVtYmVyIG9mIHRo ZSAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IG1hbnVm YWN0dXJlciAgICAgICAgfCBDS19JTkZPIHN0cnVjdHVyZSAgICB8DQogICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgbGlicmFyeS12ZXJzaW9u ICAgICAgfCBDcnlwdG9raSBsaWJyYXJ5ICAgIHwgImxpYnJhcnlWZXJzaW9u IiAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICB8IHZlcnNpb24g bnVtYmVyICAgICAgfCBtZW1iZXIgb2YgQ0tfSU5GTyAgICB8DQoNCg0KDQpQ ZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAx NSAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICBT ZXB0ZW1iZXIgMjAxNA0KDQoNCiAgIHwgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgIHwgc3RydWN0dXJlICAgICAgICAgICAg fA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IG1hbnVmYWN0 dXJlciAgICAgICAgIHwgSUQgb2YgdGhlIHRva2VuICAgICB8ICJtYW51ZmFj dHVyZXJJRCIgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBt YW51ZmFjdHVyZXIgICAgICAgIHwgbWVtYmVyIG9mICAgICAgICAgICAgfA0K ICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfCBDS19UT0tFTl9JTkZPICAgICAgICB8DQogICB8ICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IHN0cnVjdHVyZSAg ICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAg fCBtb2RlbCAgICAgICAgICAgICAgICB8IHRva2VuIG1vZGVsICAgICAgICAg fCAibW9kZWwiIG1lbWJlciBvZiAgICB8DQogICB8ICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8IENLX1RPS0VOX0lORk8g ICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgIHwgc3RydWN0dXJlICAgICAgICAgICAgfA0KICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IG9iamVjdCAgICAgICAgICAg ICAgIHwgZGVzY3JpcHRpb24gKG5hbWUpICB8ICJDS0FfTEFCRUwiIG9iamVj dCAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBvZiB0aGUgb2Jq ZWN0ICAgICAgIHwgYXR0cmlidXRlICAgICAgICAgICAgfA0KICAgKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IHNlcmlhbCAgICAgICAgICAgICAg IHwgY2hhcmFjdGVyLXN0cmluZyAgICB8ICJzZXJpYWxOdW1iZXIiICAgICAg IHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBzZXJpYWwgbnVtYmVy IG9mICAgIHwgbWVtYmVyIG9mICAgICAgICAgICAgfA0KICAgfCAgICAgICAg ICAgICAgICAgICAgICB8IHRoZSB0b2tlbiAgICAgICAgICAgfCBDS19UT0tF Tl9JTkZPICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICB8IHN0cnVjdHVyZSAgICAgICAgICAgIHwN CiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCB0b2tlbiAgICAg ICAgICAgICAgICB8IGFwcGxpY2F0aW9uLWRlZmluZWQgfCAibGFiZWwiIG1l bWJlciBvZiAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgIHwgbGFi ZWwsIGFzc2lnbmVkICAgICB8IHRoZSBDS19UT0tFTl9JTkZPICAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgfCBkdXJpbmcgdG9rZW4gICAgICAg IHwgc3RydWN0dXJlICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAg ICAgICAgICB8IGluaXRpYWxpemF0aW9uICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwg dHlwZSAgICAgICAgICAgICAgICAgfCBvYmplY3QgY2xhc3MgKHR5cGUpIHwg IkNLQV9DTEFTUyIgb2JqZWN0ICAgfA0KICAgfCAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgfCBhdHRyaWJ1dGUgICAgICAg ICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgIFRh YmxlIDE6IE1hcHBpbmcgYmV0d2VlbiBVUkkgcGF0aCBjb21wb25lbnQgYXR0 cmlidXRlcyBhbmQgUEtDUyMxMQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHNwZWNpZmljYXRpb24gbmFtZXMNCg0KICAgVGhlIHF1ZXJ5IGNvbXBv bmVudCBhdHRyaWJ1dGUgInBpbi1zb3VyY2UiIHNwZWNpZmllcyB3aGVyZSB0 aGUNCiAgIGFwcGxpY2F0aW9uIG9yIGxpYnJhcnkgc2hvdWxkIGZpbmQgdGhl IG5vcm1hbCB1c2VyJ3MgdG9rZW4gUElOLCB0aGUNCiAgICJwaW4tdmFsdWUi IGF0dHJpYnV0ZSBwcm92aWRlcyB0aGUgbm9ybWFsIHVzZXIncyBQSU4gdmFs dWUgZGlyZWN0bHksDQogICBpZiBuZWVkZWQsIGFuZCB0aGUgIm1vZHVsZS1u YW1lIiBhbmQgIm1vZHVsZS1wYXRoIiBhdHRyaWJ1dGVzIG1vZGlmeQ0KICAg ZGVmYXVsdCBzZXR0aW5ncyBmb3IgYWNjZXNzaW5nIFBLQ1MjMTEgcHJvdmlk ZXJzLiAgRm9yIHRoZSBkZWZpbml0aW9uDQogICBvZiBhICJub3JtYWwgdXNl ciIsIHNlZSBbcGtjczExX3NwZWNdLg0KDQogICBUaGUgQUJORiBydWxlcyBh Ym92ZSBpcyBhIGJlc3QgZWZmb3J0IGRlZmluaXRpb24gYW5kIHRoaXMgcGFy YWdyYXBoDQogICBzcGVjaWZpZXMgYWRkaXRpb25hbCBjb25zdHJhaW50cy4g IFRoZSBQS0NTIzExIFVSSSBtdXN0IG5vdCBjb250YWluDQogICBkdXBsaWNh dGUgYXR0cmlidXRlcyBvZiB0aGUgc2FtZSBuYW1lIGluIHRoZSBVUkkgcGF0 aCBjb21wb25lbnQuICBJdA0KICAgbWVhbnMgdGhhdCBlYWNoIGF0dHJpYnV0 ZSBtYXkgYmUgcHJlc2VudCBhdCBtb3N0IG9uY2UgaW4gdGhlIFBLQ1MjMTEN CiAgIFVSSSBwYXRoLiAgQXNpZGUgZnJvbSB0aGUgcXVlcnkgYXR0cmlidXRl cyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsDQogICBkdXBsaWNhdGUgYXR0 cmlidXRlcyBtYXkgYmUgcHJlc2VudCBpbiB0aGUgVVJJIHF1ZXJ5IGNvbXBv bmVudCBhbmQgaXQNCiAgIGlzIHVwIHRvIHRoZSBVUkkgY29uc3VtZXIgdG8g ZGVjaWRlIG9uIGhvdyB0byBkZWFsIHdpdGggc3VjaA0KICAgZHVwbGljYXRl cy4NCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgRXhwaXJl cyBNYXJjaCAyNiwgMjAxNSAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2No ZW1lICAgICAgICAgICBTZXB0ZW1iZXIgMjAxNA0KDQoNCiAgIEl0IGlzIHJl Y29tbWVuZGVkIHRvIHBlcmNlbnQtZW5jb2RlIHRoZSB3aG9sZSB2YWx1ZSBv ZiB0aGUgImlkIg0KICAgYXR0cmlidXRlIHdoaWNoIGlzIHN1cHBvc2VkIHRv IGJlIGhhbmRsZWQgYXMgYXJiaXRyYXJ5IGJpbmFyeSBkYXRhLg0KDQogICBU aGUgImxpYnJhcnktdmVyc2lvbiIgYXR0cmlidXRlIHJlcHJlc2VudHMgdGhl IG1ham9yIGFuZCBtaW5vcg0KICAgdmVyc2lvbiBudW1iZXIgb2YgdGhlIGxp YnJhcnkgYW5kIGl0cyBmb3JtYXQgaXMgIk0uTiIuICBCb3RoIG51bWJlcnMN CiAgIGFyZSBvbmUgYnl0ZSBpbiBzaXplLCBzZWUgdGhlICJsaWJyYXJ5VmVy c2lvbiIgbWVtYmVyIG9mIHRoZSBDS19JTkZPDQogICBzdHJ1Y3R1cmUgaW4g W3BrY3MxMV9zcGVjXSBmb3IgbW9yZSBpbmZvcm1hdGlvbi4gIFZhbHVlICJN IiBmb3IgdGhlDQogICBhdHRyaWJ1dGUgbXVzdCBiZSBpbnRlcnByZXRlZCBh cyAiTSIgZm9yIHRoZSBtYWpvciBhbmQgIjAiIGZvciB0aGUNCiAgIG1pbm9y IHZlcnNpb24gb2YgdGhlIGxpYnJhcnkuICBJZiB0aGUgYXR0cmlidXRlIGlz IHByZXNlbnQgdGhlIG1ham9yDQogICB2ZXJzaW9uIG51bWJlciBpcyBtYW5k YXRvcnkuDQoNCiAgIEFuIGVtcHR5IFBLQ1MjMTEgVVJJIHBhdGggYXR0cmli dXRlIHRoYXQgZG9lcyBhbGxvdyBmb3IgYW4gZW1wdHkNCiAgIHZhbHVlIG1h dGNoZXMgYSBjb3JyZXNwb25kaW5nIHN0cnVjdHVyZSBtZW1iZXIgb3IgYW4g b2JqZWN0IGF0dHJpYnV0ZQ0KICAgd2l0aCBhbiBlbXB0eSB2YWx1ZS4gIE5v dGUgdGhhdCBhY2NvcmRpbmcgdG8gdGhlIFBLQ1MjMTENCiAgIHNwZWNpZmlj YXRpb24gW3BrY3MxMV9zcGVjXSwgZW1wdHkgY2hhcmFjdGVyIHZhbHVlcyBp biBhIFBLQ1MjMTEgQVBJDQogICBwcm9kdWNlciBtdXN0IGJlIHBhZGRlZCB3 aXRoIHNwYWNlcyBhbmQgc2hvdWxkIG5vdCBiZSBOVUxMDQogICB0ZXJtaW5h dGVkLg0KDQozLjQuICBQS0NTIzExIFVSSSBTY2hlbWUgUXVlcnkgQXR0cmli dXRlIFNlbWFudGljcw0KDQogICBBbiBhcHBsaWNhdGlvbiBtYXkgYWx3YXlz IGFzayBmb3IgYSBQSU4gYnkgYW55IG1lYW5zIGl0IGRlY2lkZXMgdG8uDQog ICBXaGF0IGlzIG1vcmUsIGluIG9yZGVyIG5vdCB0byBsaW1pdCBQS0NTIzEx IFVSSSBwb3J0YWJpbGl0eSB0aGUgInBpbi0NCiAgIHNvdXJjZSIgYXR0cmli dXRlIHZhbHVlIGZvcm1hdCBhbmQgaW50ZXJwcmV0YXRpb24gaXMgbGVmdCB0 byBiZQ0KICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuICBIb3dldmVyLCB3 ZSByZWNvbW1lbmQgdGhlIGNlcnRhaW4gcnVsZXMgdG8NCiAgIGJlIGZvbGxv d2VkIGluIGRlc2NlbmRpbmcgb3JkZXIgZm9yIHRoZSB2YWx1ZSBvZiB0aGUg InBpbi1zb3VyY2UiDQogICBhdHRyaWJ1dGU6DQoNCiAgIG8gIGlmIHRoZSB2 YWx1ZSByZXByZXNlbnRzIGEgbG9jYWwgYWJzb2x1dGUgcGF0aCB0aGUgaW1w bGVtZW50YXRpb24NCiAgICAgIHNob3VsZCB1c2UgaXQgYXMgYSBQSU4gZmls ZSBjb250YWluaW5nIHRoZSBQSU4gdmFsdWUNCg0KICAgbyAgaWYgdGhlIHZh bHVlIGNvbnRhaW5zICJ8PGFic29sdXRlLWNvbW1hbmQtcGF0aD4iIHRoZQ0K ICAgICAgaW1wbGVtZW50YXRpb24gc2hvdWxkIHJlYWQgdGhlIFBJTiBmcm9t IHRoZSBvdXRwdXQgb2YgYW4NCiAgICAgIGFwcGxpY2F0aW9uIHNwZWNpZmll ZCB3aXRoIGFic29sdXRlIHBhdGggIjxhYnNvbHV0ZS1jb21tYW5kLQ0KICAg ICAgcGF0aD4iLiAgTm90ZSB0aGF0IGNoYXJhY3RlciAifCIgcmVwcmVzZW50 aW5nIGEgcGlwZSBkb2VzIG5vdCBoYXZlDQogICAgICB0byBiZSBwZXJjZW50 IGVuY29kZWQgaW4gdGhlIHF1ZXJ5IGNvbXBvbmVudCBvZiB0aGUgUEtDUyMx MSBVUkkuDQoNCiAgIG8gIGlmIHRoZSB2YWx1ZSByZXByZXNlbnRzIGEgVVJJ IHRyZWF0IGl0IGFzIGFuIG9iamVjdCBjb250YWluaW5nIHRoZQ0KICAgICAg UElOLiAgU3VjaCBhIFVSSSBtYXkgYmUgImZpbGU6IiwgImh0dHBzOiIsIGFu b3RoZXIgUEtDUyMxMSBVUkksIG9yDQogICAgICBzb21ldGhpbmcgZWxzZS4N Cg0KICAgbyAgaW50ZXJwcmV0IHRoZSB2YWx1ZSBhcyBuZWVkZWQgaW4gYW4g aW1wbGVtZW50YXRpb24gZGVwZW5kZW5kIHdheQ0KDQogICBJZiBhIFVSSSBj b250YWlucyBib3RoICJwaW4tc291cmNlIiBhbmQgInBpbi12YWx1ZSIgcXVl cnkgYXR0cmlidXRlcw0KICAgdGhlIFVSSSBzaG91bGQgYmUgcmVmdXNlZCBh cyBpbnZhbGlkLg0KDQogICBVc2Ugb2YgdGhlICJwaW4tdmFsdWUiIGF0dHJp YnV0ZSBtYXkgaGF2ZSBzZWN1cml0eSByZWxhdGVkDQogICBjb25zZXF1ZW5j ZXMuICBTZWN0aW9uIDYgc2hvdWxkIGJlIGNvbnN1bHRlZCBiZWZvcmUgdGhp cyBhdHRyaWJ1dGUgaXMNCg0KDQoNCg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAg ICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMTUgICAgICAgICAgICAgICAgIFtQ YWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgVGhlIFBLQ1Mj MTEgVVJJIFNjaGVtZSAgICAgICAgICAgU2VwdGVtYmVyIDIwMTQNCg0KDQog ICBldmVyIHVzZWQuICBTdGFuZGFyZCBwZXJjZW50IGVuY29kaW5nIHJ1bGVz IHNob3VsZCBiZSBmb2xsb3dlZCBmb3INCiAgIHRoZSBhdHRyaWJ1dGUgdmFs dWUuDQoNCiAgIEEgY29uc3VtZXIgb2YgUEtDUyMxMSBVUklzIG1heSBtb2Rp ZnkgZGVmYXVsdCBzZXR0aW5ncyBmb3IgYWNjZXNzaW5nDQogICBhIFBLQ1Mj MTEgcHJvdmlkZXIgb3IgcHJvdmlkZXJzIGJ5IGFjY2VwdGluZyBxdWVyeSBj b21wb25lbnQNCiAgIGF0dHJpYnV0ZXMgIm1vZHVsZS1uYW1lIiBhbmQgIm1v ZHVsZS1wYXRoIi4iDQoNCiAgIFByb2Nlc3NpbmcgdGhlIFVSSSBxdWVyeSBt b2R1bGUgYXR0cmlidXRlcyBzaG91bGQgZm9sbG93IHRoZXNlIHJ1bGVzOg0K DQogICBvICBhdHRyaWJ1dGUgIm1vZHVsZS1uYW1lIiBpcyBleHBlY3RlZCB0 byBjb250YWluIGEgY2FzZS1pbnNlbnNpdGl2ZQ0KICAgICAgUEtDUyMxMSBt b2R1bGUgbmFtZSAobm90IHBhdGggbm9yIGZpbGVuYW1lKSB3aXRob3V0IHN5 c3RlbQ0KICAgICAgc3BlY2lmaWMgYWZmaXhlcy4gIFN1Y2ggYWZmaXggY291 bGQgYmUgYW4gIi5zbyIgb3IgIi5ETEwiIHN1ZmZpeCwNCiAgICAgIG9yIGEg ImxpYiIgcHJlZml4LCBmb3IgZXhhbXBsZS4gIE5vdCB1c2luZyBzeXN0ZW0g c3BlY2lmaWMgYWZmaXhlcw0KICAgICAgaXMgZXhwZWN0ZWQgdG8gaW5jcmVh c2UgcG9ydGFiaWxpdHkgb2YgUEtDUyMxMSBVUklzIGFtb25nDQogICAgICBk aWZmZXJlbnQgc3lzdGVtcy4gIEEgVVJJIGNvbnN1bWVyIHNlYXJjaGluZyBm b3IgUEtDUyMxMSBtb2R1bGVzDQogICAgICBpcyBleHBlY3RlZCB0byB1c2Ug YSBzeXN0ZW0gb3IgYXBwbGljYXRpb24gc3BlY2lmaWMgbG9jYXRpb25zIHRv DQogICAgICBmaW5kIG1vZHVsZXMgYmFzZWQgb24gdGhlIG5hbWUgcHJvdmlk ZWQgaW4gdGhlIGF0dHJpYnV0ZS4NCg0KICAgbyAgYXR0cmlidXRlICJtb2R1 bGUtcGF0aCIgaXMgZXhwZWN0ZWQgdG8gY29udGFpbiBhIHN5c3RlbSBzcGVj aWZpYw0KICAgICAgYWJzb2x1dGUgcGF0aCB0byB0aGUgUEtDUyMxMSBtb2R1 bGUsIG9yIGEgc3lzdGVtIHNwZWNpZmljIGFic29sdXRlDQogICAgICBwYXRo IHRvIHRoZSBkaXJlY3Rvcnkgb2Ygd2hlcmUgUEtDUyMxMSBtb2R1bGVzIGFy ZSBsb2NhdGVkLg0KDQogICBvICB0aGUgVVJJIGNvbnN1bWVyIG1heSByZWZ1 c2UgdG8gYWNjZXB0IGVpdGhlciBvZiB0aGUgYXR0cmlidXRlcywgb3INCiAg ICAgIGJvdGguICBJZiB1c2Ugb2YgYW4gYXR0cmlidXRlIHByZXNlbnQgaW4g dGhlIFVSSSBzdHJpbmcgaXMgbm90DQogICAgICBhY2NlcHRlZCBhIHdhcm5p bmcgbWVzc2FnZSBzaG91bGQgYmUgcHJlc2VudGVkIHRvIHRoZSBwcm92aWRl ciBvZg0KICAgICAgdGhlIFVSSS4NCg0KICAgbyAgaWYgZWl0aGVyIG9mIHRo ZSBtb2R1bGUgYXR0cmlidXRlcyBpcyBwcmVzZW50LCBvbmx5IHRob3NlIG1v ZHVsZXMNCiAgICAgIGZvdW5kIG1hdGNoaW5nIHRoZXNlIHF1ZXJ5IGF0dHJp YnV0ZXMgc2hvdWxkIGJlIHVzZWQgdG8gc2VhcmNoIGZvcg0KICAgICAgYW4g b2JqZWN0IHJlcHJlc2VudGVkIGJ5IHRoZSBVUkkuDQoNCiAgIG8gIHVzZSBv ZiB0aGUgbW9kdWxlIGF0dHJpYnV0ZXMgZG9lcyBub3Qgc3VwcHJlc3MgbWF0 Y2hpbmcgb2YgYW55DQogICAgICBvdGhlciBVUkkgcGF0aCBjb21wb25lbnQg YXR0cmlidXRlcyBwcmVzZW50IGluIGEgVVJJLg0KDQogICBvICBzZW1hbnRp Y3Mgb2YgdXNpbmcgYm90aCBhdHRyaWJ1dGVzIGluIHRoZSBzYW1lIFVSSSBz dHJpbmcgaXMNCiAgICAgIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGJ1dCBz dWNoIHVzZSBzaG91bGQgYmUgYXZvaWRlZC4gIEF0dHJpYnV0ZQ0KICAgICAg Im1vZHVsZS1uYW1lIiBpcyBwcmVmZXJyZWQgdG8gIm1vZHVsZS1wYXRoIiBk dWUgdG8gaXRzIHN5c3RlbQ0KICAgICAgaW5kZXBlbmRlbnQgbmF0dXJlIGJ1 dCB0aGUgbGF0dGVyIG1heSBiZSBtb3JlIHN1aXRhYmxlIGZvcg0KICAgICAg ZGV2ZWxvcG1lbnQgYW5kIGRlYnVnZ2luZy4NCg0KICAgbyAgYSBVUkkgbWF5 IG5vdCBjb250YWluIG11bHRpcGxlIG1vZHVsZSBhdHRyaWJ1dGVzIG9mIHRo ZSBzYW1lIG5hbWUuDQoNCiAgIFVzZSBvZiB0aGUgbW9kdWxlIGF0dHJpYnV0 ZXMgbWF5IGhhdmUgc2VjdXJpdHkgcmVsYXRlZCBjb25zZXF1ZW5jZXMuDQog ICBTZWN0aW9uIDYgc2hvdWxkIGJlIGNvbnN1bHRlZCBiZWZvcmUgdGhlc2Ug YXR0cmlidXRlIGFyZSBldmVyIHVzZWQuDQoNCiAgIEEgd29yZCAibW9kdWxl IiB3YXMgY2hvc2VuIG92ZXIgd29yZCAibGlicmFyeSIgaW4gdGhlc2UgcXVl cnkNCiAgIGF0dHJpYnV0ZSBuYW1lcyB0byBhdm9pZCBjb25mdXNpb24gd2l0 aCBzZW1hbnRpY2FsbHkgZGlmZmVyZW50DQogICBsaWJyYXJ5IGF0dHJpYnV0 ZXMgdXNlZCBpbiB0aGUgVVJJIHBhdGggY29tcG9uZW50Lg0KDQoNCg0KUGVj aGFuZWMgJiBNb2ZmYXQgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYsIDIwMTUg ICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAgICAgU2Vw dGVtYmVyIDIwMTQNCg0KDQozLjUuICBQS0NTIzExIFVSSSBNYXRjaGluZyBH dWlkZWxpbmVzDQoNCiAgIFRoZSBQS0NTIzExIFVSSSBjYW4gaWRlbnRpZnkg UEtDUyMxMSBzdG9yYWdlIG9iamVjdHMsIHRva2Vucywgb3INCiAgIENyeXB0 b2tpIGxpYnJhcmllcy4gIE5vdGUgdGhhdCBzaW5jZSBhIFVSSSBtYXkgaWRl bnRpZnkgdGhyZWUNCiAgIGRpZmZlcmVudCB0eXBlcyBvZiBlbnRpdGllcyB0 aGUgY29udGV4dCB3aXRoaW4gd2hpY2ggdGhlIFVSSSBpcyB1c2VkDQogICBt YXkgYmUgbmVlZGVkIHRvIGRldGVybWluZSB0aGUgdHlwZS4gIEZvciBleGFt cGxlLCBhIFVSSSB3aXRoIG9ubHkNCiAgIGxpYnJhcnkgYXR0cmlidXRlcyBt YXkgZWl0aGVyIHJlcHJlc2VudCBhbGwgb2JqZWN0cyBpbiBhbGwgdG9rZW5z IGluDQogICBhbGwgQ3J5cHRva2kgbGlicmFyaWVzIGlkZW50aWZpZWQgYnkg dGhlIFVSSSwgYWxsIHRva2VucyBpbiB0aG9zZQ0KICAgbGlicmFyaWVzLCBv ciBqdXN0IHRoZSBsaWJyYXJpZXMuDQoNCiAgIFRoZSBmb2xsb3dpbmcgZ3Vp ZGVsaW5lcyBzaG91bGQgaGVscCBhIFBLQ1MjMTEgVVJJIGNvbnN1bWVyIChl Zy4gYW4NCiAgIGFwcGxpY2F0aW9uIGFjY2VwdGluZyBQS0NTIzExIFVSSXMp IHRvIG1hdGNoIHRoZSBVUkkgd2l0aCB0aGUgZGVzaXJlZA0KICAgcmVzb3Vy Y2UuDQoNCiAgIG8gIHRoZSBjb25zdW1lciBtdXN0IGtub3cgd2hldGhlciB0 aGUgVVJJIGlzIHRvIGlkZW50aWZ5IFBLQ1MjMTENCiAgICAgIHN0b3JhZ2Ug b2JqZWN0KHMpLCB0b2tlbihzKSwgb3IgQ3J5cHRva2kgcHJvZHVjZXIocyku DQoNCiAgIG8gIGlmIHRoZSBjb25zdW1lciBpcyB3aWxsaW5nIHRvIGFjY2Vw dCBxdWVyeSBjb21wb25lbnQgbW9kdWxlDQogICAgICBhdHRyaWJ1dGVzIG9u bHkgdGhvc2UgUEtDUyMxMSBwcm92aWRlcnMgbWF0Y2hpbmcgdGhlc2UgYXR0 cmlidXRlcw0KICAgICAgc2hvdWxkIGJlIHdvcmtlZCB3aXRoLiAgU2VlIFNl Y3Rpb24gMy40IGZvciBtb3JlIGluZm9ybWF0aW9uLg0KDQogICBvICBhbiB1 bnJlY29nbml6ZWQgYXR0cmlidXRlIGluIHRoZSBVUkkgcGF0aCBjb21wb25l bnQsIGluY2x1ZGluZyBhDQogICAgICB2ZW5kb3Igc3BlY2lmaWMgYXR0cmli dXRlLCBzaG91bGQgcmVzdWx0IGluIGFuIGVtcHR5IHNldCBvZg0KICAgICAg bWF0Y2hlZCByZXNvdXJjZXMuICBUaGUgY29uc3VtZXIgc2hvdWxkIGNvbnNp ZGVyIHdoZXRoZXIgYW4gZXJyb3INCiAgICAgIG1lc3NhZ2UgcHJlc2VudGVk IHRvIHRoZSB1c2VyIGlzIGFwcHJvcHJpYXRlIGluIHN1Y2ggYSBjYXNlLg0K DQogICBvICBhbiB1bnJlY29nbml6ZWQgYXR0cmlidXRlIGluIHRoZSBVUkkg cXVlcnkgc2hvdWxkIGJlIGlnbm9yZWQuICBUaGUNCiAgICAgIGNvbnN1bWVy IHNob3VsZCBjb25zaWRlciB3aGV0aGVyIGEgd2FybmluZyBtZXNzYWdlIHBy ZXNlbnRlZCB0bw0KICAgICAgdGhlIHVzZXIgaXMgYXBwcm9wcmlhdGUgaW4g c3VjaCBhIGNhc2UuDQoNCiAgIG8gIGFuIGF0dHJpYnV0ZSBub3QgcHJlc2Vu dCBpbiB0aGUgVVJJIHBhdGggYnV0IGtub3duIHRvIGEgY29uc3VtZXINCiAg ICAgIG1hdGNoZXMgZXZlcnl0aGluZy4gIEVhY2ggYWRkaXRpb25hbCBhdHRy aWJ1dGUgcHJlc2VudCBpbiB0aGUgVVJJDQogICAgICBwYXRoIGZ1cnRoZXIg cmVzdHJpY3RzIHRoZSBzZWxlY3Rpb24uDQoNCiAgIG8gIGEgbG9naWNhbCBl eHRlbnNpb24gb2YgdGhlIGFib3ZlIGlzIHRoYXQgYW4gZW1wdHkgVVJJIHBh dGggbWF0Y2hlcw0KICAgICAgZXZlcnl0aGluZy4gIEZvciBleGFtcGxlLCBp ZiB1c2VkIHRvIGlkZW50aWZ5IHN0b3JhZ2Ugb2JqZWN0cyBpdA0KICAgICAg bWF0Y2hlcyBhbGwgYWNjZXNzaWJsZSBvYmplY3RzIGluIGFsbCB0b2tlbnMg cHJvdmlkZWQgYnkgYWxsDQogICAgICBQS0NTIzExIEFQSSBwcm9kdWNlcnMg Zm91bmQgaW4gdGhlIHN5c3RlbS4NCg0KICAgbyAgdXNlIG9mIFBJTiBhdHRy aWJ1dGVzIG1heSBjaGFuZ2UgdGhlIHNldCBvZiBzdG9yYWdlIG9iamVjdHMN CiAgICAgIHZpc2libGUgdG8gdGhlIGNvbnN1bWVyLg0KDQogICBvICBpbiBh ZGRpdGlvbiB0byBxdWVyeSBjb21wb25lbnQgYXR0cmlidXRlcyBkZWZpbmVk IGluIHRoaXMNCiAgICAgIGRvY3VtZW50LCB2ZW5kb3Igc3BlY2lmaWMgcXVl cnkgYXR0cmlidXRlcyBtYXkgY29udGFpbiBmdXJ0aGVyDQogICAgICBpbmZv cm1hdGlvbiBhYm91dCBob3cgdG8gcGVyZm9ybSB0aGUgc2VsZWN0aW9uIG9y IG90aGVyIHJlbGF0ZWQNCiAgICAgIGluZm9ybWF0aW9uLg0KDQoNCg0KDQoN ClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICBFeHBpcmVzIE1hcmNoIDI2LCAy MDE1ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAgICAgICAg IFNlcHRlbWJlciAyMDE0DQoNCg0KMy42LiAgUEtDUyMxMSBVUkkgQ29tcGFy aXNvbg0KDQogICBDb21wYXJpc29uIG9mIHR3byBVUklzIGlzIGEgd2F5IG9m IGRldGVybWluaW5nIHdoZXRoZXIgdGhlIFVSSXMgYXJlDQogICBlcXVpdmFs ZW50IHdpdGhvdXQgY29tcGFyaW5nIHRoZSBhY3R1YWwgcmVzb3VyY2UgdGhl IFVSSXMgcG9pbnQgdG8uDQogICBUaGUgY29tcGFyaXNvbiBvZiBVUklzIGFp bXMgdG8gbWluaW1pemUgZmFsc2UgbmVnYXRpdmVzIHdoaWxlDQogICBzdHJp Y3RseSBhdm9pZGluZyBmYWxzZSBwb3NpdGl2ZXMuDQoNCiAgIFR3byBQS0NT IzExIFVSSXMgYXJlIHNhaWQgdG8gYmUgZXF1YWwgaWYgVVJJcyBhcyBjaGFy YWN0ZXIgc3RyaW5ncw0KICAgYXJlIGlkZW50aWNhbCBhcyBzcGVjaWZpZWQg aW4gU2VjdGlvbiA2LjIuMSBvZiBbUkZDMzk4Nl0sIG9yIGlmIGJvdGgNCiAg IGZvbGxvd2luZyBydWxlcyBhcmUgZnVsZmlsbGVkOg0KDQogICBvICBzZXQg b2YgYXR0cmlidXRlcyBwcmVzZW50IGluIHRoZSBVUkkgaXMgZXF1YWwuICBO b3RlIHRoYXQgdGhlDQogICAgICBvcmRlcmluZyBvZiBhdHRyaWJ1dGVzIGlu IHRoZSBVUkkgc3RyaW5nIGlzIG5vdCBzaWduaWZpY2FudCBmb3INCiAgICAg IHRoZSBtZWNoYW5pc20gb2YgY29tcGFyaXNvbi4NCg0KICAgbyAgdmFsdWVz IG9mIHJlc3BlY3RpdmUgYXR0cmlidXRlcyBhcmUgZXF1YWwgYmFzZWQgb24g cnVsZXMgc3BlY2lmaWVkDQogICAgICBiZWxvdw0KDQogICBUaGUgcnVsZXMg Zm9yIGNvbXBhcmluZyB2YWx1ZXMgb2YgcmVzcGVjdGl2ZSBhdHRyaWJ1dGVz IGFyZToNCg0KICAgbyAgdmFsdWVzIG9mIHBhdGggY29tcG9uZW50IGF0dHJp YnV0ZXMgImxpYnJhcnktZGVzY3JpcHRpb24iLA0KICAgICAgImxpYnJhcnkt bWFudWZhY3R1cmVyIiwgIm1hbnVmYWN0dXJlciIsICJtb2RlbCIsICJvYmpl Y3QiLA0KICAgICAgInNlcmlhbCIsICJ0b2tlbiIsICJ0eXBlIiwgYW5kIHF1 ZXJ5IGNvbXBvbmVudCBhdHRyaWJ1dGUgIm1vZHVsZS0NCiAgICAgIG5hbWUi IG11c3QgYmUgY29tcGFyZWQgdXNpbmcgYSBzaW1wbGUgc3RyaW5nIGNvbXBh cmlzb24gYXMNCiAgICAgIHNwZWNpZmllZCBpbiBTZWN0aW9uIDYuMi4xIG9m IFtSRkMzOTg2XSBhZnRlciB0aGUgY2FzZSBhbmQgdGhlDQogICAgICBwZXJj ZW50LWVuY29kaW5nIG5vcm1hbGl6YXRpb24gYXJlIGJvdGggYXBwbGllZCBh cyBzcGVjaWZpZWQgaW4NCiAgICAgIFNlY3Rpb24gNi4yLjIgb2YgW1JGQzM5 ODZdLg0KDQogICBvICB2YWx1ZSBvZiBhdHRyaWJ1dGUgImlkIiBtdXN0IGJl IGNvbXBhcmVkIHVzaW5nIHRoZSBzaW1wbGUgc3RyaW5nDQogICAgICBjb21w YXJpc29uIGFmdGVyIGFsbCBieXRlcyBhcmUgcGVyY2VudC1lbmNvZGVkIHVz aW5nIHVwcGVyY2FzZQ0KICAgICAgbGV0dGVycyBmb3IgZGlnaXRzIEEtRi4N Cg0KICAgbyAgdmFsdWUgb2YgInBpbi1zb3VyY2UiLCBpZiBkZWVtZWQgY29u dGFpbmluZyB0aGUgZmlsZW5hbWUgd2l0aCB0aGUNCiAgICAgIFBJTiB2YWx1 ZSwgbXVzdCBiZSBjb21wYXJlZCB1c2luZyB0aGUgc2ltcGxlIHN0cmluZyBj b21wYXJpc29uDQogICAgICBhZnRlciB0aGUgZnVsbCBzeW50YXggYmFzZWQg bm9ybWFsaXphdGlvbiBhcyBzcGVjaWZpZWQgaW4NCiAgICAgIFNlY3Rpb24g Ni4yLjIgb2YgW1JGQzM5ODZdIGlzIGFwcGxpZWQuICBJZiB2YWx1ZSBvZiB0 aGUgInBpbi0NCiAgICAgIHNvdXJjZSIgYXR0cmlidXRlIGlzIGJlbGlldmVk IHRvIGJlIG92ZXJsb2FkZWQgaXQgaXMgcmVjb21tZW5kZWQNCiAgICAgIHRv IHBlcmZvcm0gY2FzZSBhbmQgcGVyY2VudC1lbmNvZGluZyBub3JtYWxpemF0 aW9uIGJlZm9yZSB0aGUNCiAgICAgIHZhbHVlcyBhcmUgY29tcGFyZWQgYnV0 IHRoZSBleGFjdCBtZWNoYW5pc20gb2YgY29tcGFyaXNvbiBpcyBsZWZ0DQog ICAgICB0byB0aGUgYXBwbGljYXRpb24uDQoNCiAgIG8gIHZhbHVlIG9mIGF0 dHJpYnV0ZSAibW9kdWxlLXBhdGgiIG11c3QgYmUgY29tcGFyZWQgdXNpbmcg dGhlIHNpbXBsZQ0KICAgICAgc3RyaW5nIGNvbXBhcmlzb24gYWZ0ZXIgdGhl IGZ1bGwgc3ludGF4IGJhc2VkIG5vcm1hbGl6YXRpb24gYXMNCiAgICAgIHNw ZWNpZmllZCBpbiBTZWN0aW9uIDYuMi4yIG9mIFtSRkMzOTg2XSBpcyBhcHBs aWVkLg0KDQogICBvICB2YWx1ZSBvZiBhdHRyaWJ1dGUgImxpYnJhcnktdmVy c2lvbiIgbXVzdCBiZSBwcm9jZXNzZWQgYXMgYQ0KICAgICAgc3BlY2lmaWMg c2NoZW1lLWJhc2VkIG5vcm1hbGl6YXRpb24gcGVybWl0dGVkIGJ5IFNlY3Rp b24gNi4yLjMgb2YNCiAgICAgIFtSRkMzOTg2XS4gIFRoZSB2YWx1ZSBtdXN0 IGJlIHNwbGl0IGludG8gYSBtYWpvciBhbmQgbWlub3IgdmVyc2lvbg0KDQoN Cg0KUGVjaGFuZWMgJiBNb2ZmYXQgICAgICAgIEV4cGlyZXMgTWFyY2ggMjYs IDIwMTUgICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgVGhlIFBLQ1MjMTEgVVJJIFNjaGVtZSAgICAgICAg ICAgU2VwdGVtYmVyIDIwMTQNCg0KDQogICAgICB3aXRoIGNoYXJhY3RlciAn LicgKGRvdCkgc2VydmluZyBhcyBhIGRlbGltaXRlci4gIExpYnJhcnkgdmVy c2lvbg0KICAgICAgIk0iIG11c3QgYmUgdHJlYXRlZCBhcyAiTSIgZm9yIHRo ZSBtYWpvciB2ZXJzaW9uIGFuZCAiMCIgZm9yIHRoZQ0KICAgICAgbWlub3Ig dmVyc2lvbi4gIFJlc3VsdGluZyBtaW5vciBhbmQgbWFqb3IgdmVyc2lvbiBu dW1iZXJzIG11c3QgYmUNCiAgICAgIHRoZW4gc2VwYXJhdGVseSBjb21wYXJl ZCBudW1lcmljYWxseS4NCg0KICAgbyAgd2hlbiBjb21wYXJpbmcgdmVuZG9y IHNwZWNpZmljIGF0dHJpYnV0ZXMgaXQgaXMgcmVjb21tZW5kZWQgdG8NCiAg ICAgIHBlcmZvcm0gY2FzZSBhbmQgcGVyY2VudC1lbmNvZGluZyBub3JtYWxp emF0aW9uIGJlZm9yZSB0aGUgdmFsdWVzDQogICAgICBhcmUgY29tcGFyZWQg YnV0IHRoZSBleGFjdCBtZWNoYW5pc20gb2YgY29tcGFyaXNvbiBpcyBsZWZ0 IHRvIHRoZQ0KICAgICAgYXBwbGljYXRpb24uDQoNCjQuICBFeGFtcGxlcyBv ZiBQS0NTIzExIFVSSXMNCg0KICAgVGhpcyBzZWN0aW9uIGNvbnRhaW5zIHNv bWUgZXhhbXBsZXMgb2YgaG93IFBLQ1MjMTEgdG9rZW4gb2JqZWN0cywNCiAg IFBLQ1MjMTEgdG9rZW5zLCBhbmQgUEtDUyMxMSBsaWJyYXJpZXMgY2FuIGJl IGlkZW50aWZpZWQgdXNpbmcgdGhlDQogICBQS0NTIzExIFVSSSBzY2hlbWUu ICBOb3RlIHRoYXQgaW4gc29tZSBvZiB0aGUgZm9sbG93aW5nIGV4YW1wbGVz LA0KICAgbmV3bGluZXMgYW5kIHNwYWNlcyB3ZXJlIGluc2VydGVkIGZvciBi ZXR0ZXIgcmVhZGFiaWxpdHkuICBBcw0KICAgc3BlY2lmaWVkIGluIEFwcGVu ZGl4IEMgb2YgW1JGQzM5ODZdLCB3aGl0ZXNwYWNlIHNob3VsZCBiZSBpZ25v cmVkDQogICB3aGVuIGV4dHJhY3RpbmcgdGhlIFVSSS4gIEFsc28gbm90ZSB0 aGF0IGFsbCBzcGFjZXMgYXMgcGFydCBvZiB0aGUNCiAgIFVSSSBhcmUgcGVy Y2VudC1lbmNvZGVkLCBhcyBzcGVjaWZpZWQgaW4gQXBwZW5kaXggQSBvZiBb UkZDMzk4Nl0uDQoNCiAgIEFuIGVtcHR5IFBLQ1MjMTEgVVJJIG1pZ2h0IGJl IHVzZWZ1bCB0byBQS0NTIzExIGNvbnN1bWVycy4gIFNlZQ0KICAgU2VjdGlv biAzLjUgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gc2VtYW50aWNzIG9mIHN1 Y2ggYSBVUkkuDQoNCiAgICAgcGtjczExOg0KDQogICBPbmUgb2YgdGhlIHNp bXBsZXN0IGFuZCBtb3N0IHVzZWZ1bCBmb3JtcyBtaWdodCBiZSBhIFBLQ1Mj MTEgVVJJIHRoYXQNCiAgIHNwZWNpZmllcyBvbmx5IGFuIG9iamVjdCBsYWJl bCBhbmQgaXRzIHR5cGUuICBUaGUgZGVmYXVsdCB0b2tlbiBpcw0KICAgdXNl ZCBzbyB0aGUgVVJJIGRvZXMgbm90IHNwZWNpZnkgaXQuICBOb3RlIHRoYXQg d2hlbiBzcGVjaWZ5aW5nDQogICBwdWJsaWMgb2JqZWN0cywgYSB0b2tlbiBQ SU4gbWlnaHQgbm90IGJlIHJlcXVpcmVkLg0KDQogICAgIHBrY3MxMTpvYmpl Y3Q9bXktcHVia2V5O3R5cGU9cHVibGljDQoNCiAgIFdoZW4gYSBwcml2YXRl IGtleSBpcyBzcGVjaWZpZWQgZWl0aGVyIHRoZSAicGluLXNvdXJjZSIgYXR0 cmlidXRlLA0KICAgInBpbi12YWx1ZSwgb3IgYW4gYXBwbGljYXRpb24gc3Bl Y2lmaWMgbWV0aG9kIHdvdWxkIGJlIHVzdWFsbHkgdXNlZC4NCiAgIE5vdGUg dGhhdCAnLycgaXMgbm90IHBlcmNlbnQtZW5jb2RlZCBpbiB0aGUgInBpbi1z b3VyY2UiIGF0dHJpYnV0ZQ0KICAgdmFsdWUgc2luY2UgdGhpcyBhdHRyaWJ1 dGUgaXMgcGFydCBvZiB0aGUgcXVlcnkgY29tcG9uZW50LCBub3QgdGhlDQog ICBwYXRoLCBhbmQgdGh1cyBpcyBzZXBhcmF0ZWQgYnkgJz8nIGZyb20gdGhl IHJlc3Qgb2YgdGhlIFVSSS4NCg0KICAgICBwa2NzMTE6b2JqZWN0PW15LWtl eTt0eXBlPXByaXZhdGU/cGluLXNvdXJjZT0vZXRjL3Rva2VuDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgRXhw aXJlcyBNYXJjaCAyNiwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxMl0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkg U2NoZW1lICAgICAgICAgICBTZXB0ZW1iZXIgMjAxNA0KDQoNCiAgIFRoZSBm b2xsb3dpbmcgZXhhbXBsZSBpZGVudGlmaWVzIGEgY2VydGlmaWNhdGUgaW4g dGhlIHNvZnR3YXJlIHRva2VuLg0KICAgTm90ZSBhbiBlbXB0eSB2YWx1ZSBm b3IgdGhlIGF0dHJpYnV0ZSAic2VyaWFsIi4gIEFsc28gbm90ZSB0aGF0IHRo ZQ0KICAgImlkIiBhdHRyaWJ1dGUgdmFsdWUgaXMgZW50aXJlbHkgcGVyY2Vu dC1lbmNvZGVkLCBhcyByZWNvbW1lbmRlZC4NCiAgIFdoaWxlICcsJyBpcyBp biB0aGUgcmVzZXJ2ZWQgc2V0IGl0IGRvZXMgbm90IGhhdmUgdG8gYmUgcGVy Y2VudC0NCiAgIGVuY29kZWQgc2luY2UgaXQgZG9lcyBub3QgY29uZmxpY3Qg d2l0aCBhbnkgc3ViLWRlbGltaXRlcnMgdXNlZC4gIFRoZQ0KICAgJyMnIGNo YXJhY3RlciBhcyBpbiAiVGhlIFNvZnR3YXJlIFBLQ1MjMTEgU29mdHRva2Vu IiBtdXN0IGJlIHBlcmNlbnQtDQogICBlbmNvZGVkLg0KDQogICAgIHBrY3Mx MTp0b2tlbj1UaGUlMjBTb2Z0d2FyZSUyMFBLQ1MlMjMxMSUyMFNvZnR0b2tl bjsNCiAgICAgICAgICAgIG1hbnVmYWN0dXJlcj1TbmFrZSUyME9pbCwlMjBJ bmMuOw0KICAgICAgICAgICAgbW9kZWw9MS4wOw0KICAgICAgICAgICAgb2Jq ZWN0PW15LWNlcnRpZmljYXRlOw0KICAgICAgICAgICAgdHlwZT1jZXJ0Ow0K ICAgICAgICAgICAgaWQ9JTY5JTk1JTNFJTVDJUY0JUJEJUVDJTkxOw0KICAg ICAgICAgICAgc2VyaWFsPQ0KICAgICAgICAgICAgP3Bpbi1zb3VyY2U9L2V0 Yy90b2tlbl9waW4NCg0KICAgVGhlIG5leHQgZXhhbXBsZSBjb3ZlcnMgaG93 IHRvIHVzZSB0aGUgIm1vZHVsZS1uYW1lIiBxdWVyeSBhdHRyaWJ1dGUuDQog ICBDb25zaWRlcmluZyB0aGF0IHRoZSBtb2R1bGUgaXMgbG9jYXRlZCBpbiAv dXNyL2xpYi9saWJteXBrY3MxMS5zby4xDQogICBmaWxlLCB0aGUgYXR0cmli dXRlIHZhbHVlIGlzICJteXBrY3MxMSIsIGllLiAgb25seSB0aGUgbW9kdWxl IG5hbWUNCiAgIHdpdGhvdXQgdGhlIGZ1bGwgcGF0aCwgYW5kIHdpdGhvdXQg dGhlIHBsYXRmb3JtIHNwZWNpZmljICJsaWIiIHByZWZpeA0KICAgYW5kICIu c28uMSIgc3VmZml4Lg0KDQogICAgIHBrY3MxMTpvYmplY3Q9bXktc2lnbi1r ZXk7DQogICAgICAgICAgICB0eXBlPXByaXZhdGUNCiAgICAgICAgICAgID9t b2R1bGUtbmFtZT1teXBrY3MxMQ0KDQogICBUaGUgZm9sbG93aW5nIGV4YW1w bGUgY292ZXJzIGhvdyB0byB1c2UgdGhlICJtb2R1bGUtcGF0aCIgcXVlcnkN CiAgIGF0dHJpYnV0ZS4gIFRoZSBhdHRyaWJ1dGUgbWF5IGJlIHVzZWZ1bCBp ZiBhIHVzZXIgbmVlZHMgdG8gcHJvdmlkZQ0KICAgdGhlIGtleSB2aWEgYSBQ S0NTIzExIG1vZHVsZSBzdG9yZWQgb24gYSByZW1vdmFibGUgbWVkaWEsIGZv cg0KICAgZXhhbXBsZS4NCg0KICAgICBwa2NzMTE6b2JqZWN0PW15LXNpZ24t a2V5Ow0KICAgICAgICAgICAgdHlwZT1wcml2YXRlDQogICAgICAgICAgICA/ bW9kdWxlLXBhdGg9L21udC9saWJteXBrY3MxMS5zby4xDQoNCiAgIEluIHRo ZSBjb250ZXh0IHdoZXJlIGEgdG9rZW4gaXMgZXhwZWN0ZWQgdGhlIHRva2Vu IGNhbiBiZSBpZGVudGlmaWVkDQogICB3aXRob3V0IHNwZWNpZnlpbmcgYW55 IFBLQ1MjMTEgb2JqZWN0cy4gIEEgUElOIG1pZ2h0IHN0aWxsIGJlIG5lZWRl ZA0KICAgaW4gdGhlIGNvbnRleHQgb2YgbGlzdGluZyBhbGwgb2JqZWN0cyBp biB0aGUgdG9rZW4sIGZvciBleGFtcGxlLg0KICAgU2VjdGlvbiA2IHNob3Vs ZCBiZSBjb25zdWx0ZWQgYmVmb3JlIHRoZSAicGluLXZhbHVlIiBhdHRyaWJ1 dGUgaXMNCiAgIGV2ZXIgdXNlZC4NCg0KICAgICBwa2NzMTE6dG9rZW49U29m dHdhcmUlMjBQS0NTJTIzMTElMjBzb2Z0dG9rZW47DQogICAgICAgICAgICBt YW51ZmFjdHVyZXI9U25ha2UlMjBPaWwsJTIwSW5jLg0KICAgICAgICAgICAg P3Bpbi12YWx1ZT10aGUtcGluDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1v ZmZhdCAgICAgICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAxNSAgICAgICAgICAg ICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBU aGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAgICAgICBTZXB0ZW1iZXIgMjAx NA0KDQoNCiAgIFRoZSBDcnlwdG9raSBsaWJyYXJ5IGFsb25lIGNhbiBiZSBh bHNvIGlkZW50aWZpZWQgd2l0aG91dCBzcGVjaWZ5aW5nDQogICBhIFBLQ1Mj MTEgdG9rZW4gb3Igb2JqZWN0Lg0KDQogICAgIHBrY3MxMTpsaWJyYXJ5LW1h bnVmYWN0dXJlcj1TbmFrZSUyME9pbCwlMjBJbmMuOw0KICAgICAgICAgICAg bGlicmFyeS1kZXNjcmlwdGlvbj1Tb2Z0JTIwVG9rZW4lMjBMaWJyYXJ5Ow0K ICAgICAgICAgICAgbGlicmFyeS12ZXJzaW9uPTEuMjMNCg0KICAgVGhlIGZv bGxvd2luZyBleGFtcGxlIHNob3dzIHRoYXQgdGhlIGF0dHJpYnV0ZSB2YWx1 ZSBjYW4gY29udGFpbiBhDQogICBzZW1pY29sb24uICBJbiBzdWNoIGNhc2Us IGl0IGlzIHBlcmNlbnQtZW5jb2RlZC4gIFRoZSB0b2tlbiBhdHRyaWJ1dGUN CiAgIHZhbHVlIG11c3QgYmUgcmVhZCBhcyAiTXkgdG9rZW47IGNyZWF0ZWQg YnkgSm9lIi4gIExvd2VyIGNhc2UgbGV0dGVycw0KICAgY2FuIGFsc28gYmUg dXNlZCBpbiBwZXJjZW50LWVuY29kaW5nIGFzIHNob3duIGJlbG93IGluIHRo ZSAiaWQiDQogICBhdHRyaWJ1dGUgdmFsdWUgYnV0IG5vdGUgdGhhdCBTZWN0 aW9ucyAyLjEgYW5kIDYuMi4yLjEgb2YgW1JGQzM5ODZdDQogICByZWFkIHRo YXQgYWxsIHBlcmNlbnQtZW5jb2RlZCBjaGFyYWN0ZXJzIHNob3VsZCB1c2Ug dGhlIHVwcGVyY2FzZQ0KICAgaGV4YWRlY2ltYWwgZGlnaXRzLiAgTW9yZSBz cGVjaWZpY2FsbHksIGlmIHRoZSBVUkkgc3RyaW5nIHdhcyB0byBiZQ0KICAg Y29tcGFyZWQsIHRoZSBhbGdvcml0aG0gZGVmaW5lZCBpbiBTZWN0aW9uIDMu NiBleHBsaWNpdGx5IHJlcXVpcmVzDQogICBwZXJjZW50LWVuY29kaW5nIHRv IHVzZSB0aGUgdXBwZXJjYXNlIGRpZ2l0cyBBLUYgaW4gdGhlICJpZCINCiAg IGF0dHJpYnV0ZSB2YWx1ZXMuICBBbmQgYXMgZXhwbGFpbmVkIGluIFNlY3Rp b24gMy4zLCBsaWJyYXJ5IHZlcnNpb24NCiAgICIzIiBzaG91bGQgYmUgaW50 ZXJwcmV0ZWQgYXMgIjMiIGZvciB0aGUgbWFqb3IgYW5kICIwIiBmb3IgdGhl IG1pbm9yDQogICB2ZXJzaW9uIG9mIHRoZSBsaWJyYXJ5Lg0KDQogICAgIHBr Y3MxMTp0b2tlbj1NeSUyMHRva2VuJTI1JTIwY3JlYXRlZCUyMGJ5JTIwSm9l Ow0KICAgICAgICAgICAgbGlicmFyeS12ZXJzaW9uPTM7DQogICAgICAgICAg ICBpZD0lMDElMDIlMDMlQmElZGQlQ2ElZmUlMDQlMDUlMDYNCg0KICAgSWYg dGhlcmUgaXMgYW55IG5lZWQgdG8gaW5jbHVkZSBsaXRlcmFsICIlOyIgc3Vi c3RyaW5nLCBmb3IgZXhhbXBsZSwNCiAgIGJvdGggY2hhcmFjdGVycyBtdXN0 IGJlIGVzY2FwZWQuICBUaGUgdG9rZW4gdmFsdWUgbXVzdCBiZSByZWFkIGFz ICJBDQogICBuYW1lIHdpdGggYSBzdWJzdHJpbmcgJTsiLg0KDQogICAgIHBr Y3MxMTp0b2tlbj1BJTIwbmFtZSUyMHdpdGglMjBhJTIwc3Vic3RyaW5nJTIw JTI1JTNCOw0KICAgICAgICAgICAgb2JqZWN0PW15LWNlcnRpZmljYXRlOw0K ICAgICAgICAgICAgdHlwZT1jZXJ0DQogICAgICAgICAgICA/cGluLXNvdXJj ZT0vZXRjL3Rva2VuX3Bpbg0KDQogICBUaGUgbmV4dCBleGFtcGxlIGluY2x1 ZGVzIGEgc21hbGwgQSB3aXRoIGFjdXRlIGluIHRoZSB0b2tlbiBuYW1lLiAg SXQNCiAgIG11c3QgYmUgZW5jb2RlZCBpbiBvY3RldHMgYWNjb3JkaW5nIHRv IHRoZSBVVEYtOCBjaGFyYWN0ZXIgZW5jb2RpbmcNCiAgIGFuZCB0aGVuIHBl cmNlbnQtZW5jb2RlZC4gIEdpdmVuIHRoYXQgYSBzbWFsbCBBIHdpdGggYWN1 dGUgaXMgVSsyMjUNCiAgIHVuaWNvZGUgY29kZSBwb2ludCwgdGhlIFVURi04 IGVuY29kaW5nIGlzIDE5NSAxNjEgaW4gZGVjaW1hbCwgYW5kDQogICB0aGF0 IGlzICIlQzMlQTEiIGluIHBlcmNlbnQtZW5jb2RpbmcuDQoNCiAgICAgcGtj czExOnRva2VuPU5hbWUlMjB3aXRoJTIwYSUyMHNtYWxsJTIwQSUyMHdpdGgl MjBhY3V0ZTolMjAlQzMlQTE7DQogICAgICAgICAgICBvYmplY3Q9bXktY2Vy dGlmaWNhdGU7DQogICAgICAgICAgICB0eXBlPWNlcnQNCg0KDQoNCg0KDQoN Cg0KDQoNClBlY2hhbmVjICYgTW9mZmF0ICAgICAgICBFeHBpcmVzIE1hcmNo IDI2LCAyMDE1ICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgIFRoZSBQS0NTIzExIFVSSSBTY2hlbWUgICAg ICAgICAgIFNlcHRlbWJlciAyMDE0DQoNCg0KICAgQm90aCB0aGUgcGF0aCBh bmQgcXVlcnkgY29tcG9uZW50cyBtYXkgY29udGFpbiB2ZW5kb3Igc3BlY2lm aWMNCiAgIGF0dHJpYnV0ZXMuICBBdHRyaWJ1dGVzIGluIHRoZSBxdWVyeSBj b21wb25lbnQgbWF5IGJlIGRlbGltaXRlZCBieQ0KICAgZWl0aGVyICc7JyBv ciAnJicuICBXZSB1c2UgJyYnIGluIHRoZSBleGFtcGxlIHRoYXQgZm9sbG93 cy4NCg0KICAgICBwa2NzMTE6dG9rZW49bXktdG9rZW47DQogICAgICAgICAg ICBvYmplY3Q9bXktY2VydGlmaWNhdGU7DQogICAgICAgICAgICB0eXBlPWNl cnQ7DQogICAgICAgICAgICB4LXZlbmQtYWFhPXZhbHVlLWENCiAgICAgICAg ICAgID9waW4tc291cmNlPS9ldGMvdG9rZW5fcGluJg0KICAgICAgICAgICAg eC12ZW5kLWJiYj12YWx1ZS1iDQoNCjUuICBJQU5BIENvbnNpZGVyYXRpb25z DQoNCiAgIFRoaXMgZG9jdW1lbnQgbW92ZXMgdGhlICJwa2NzMTEiIFVSSSBz Y2hlbWUgZnJvbSB0aGUgcHJvdmlzaW9uYWwgdG8NCiAgIHRoZSBwZXJtYW5l bnQgVVJJIHNjaGVtZSByZWdpc3RyeS4gIFRoZSByZWdpc3RyYXRpb24gdGVt cGxhdGUgZm9yIHRoZQ0KICAgVVJJIHNjaGVtZSBpcyBhY2Nlc3NpYmxlIG9u IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdXJpLQ0KICAgc2No ZW1lcy4NCg0KNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRo ZXJlIGFyZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBV Ukkgc2NoZW1lcyBkaXNjdXNzZWQNCiAgIGluIFNlY3Rpb24gNyBvZiBbUkZD Mzk4Nl0uDQoNCiAgIEZyb20gdGhvc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMsIFNlY3Rpb24gNy4xIG9mIFtSRkMzOTg2XSBhcHBsaWVzDQogICBzaW5j ZSB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCB0aGUgc2FtZSBQS0NTIzEx IFVSSSB3aWxsIGFsd2F5cw0KICAgaWRlbnRpZnkgdGhlIHNhbWUgb2JqZWN0 LCB0b2tlbiwgb3IgYSBsaWJyYXJ5IGluIHRoZSBmdXR1cmUuDQoNCiAgIFNl Y3Rpb24gNy4yIG9mIFtSRkMzOTg2XSBhcHBsaWVzIHNpbmNlIGJ5IGFjY2Vw dGluZyBxdWVyeSBjb21wb25lbnQNCiAgIGF0dHJpYnV0ZXMgIm1vZHVsZS1u YW1lIiBvciAibW9kdWxlLXBhdGgiIHRoZSBjb25zdW1lciBwb3RlbnRpYWxs eQ0KICAgYWxsb3dzIGxvYWRpbmcgb2YgYXJiaXRyYXJ5IGNvZGUgaW50byBh IHByb2Nlc3MuDQoNCiAgIFNlY3Rpb24gNy41IG9mIFtSRkMzOTg2XSBhcHBs aWVzIHNpbmNlIHRoZSBQS0NTIzExIFVSSSBtYXkgYmUgdXNlZCBpbg0KICAg d29ybGQgcmVhZGFibGUgY29tbWFuZCBsaW5lIGFyZ3VtZW50cyB0byBydW4g YXBwbGljYXRpb25zLCBzdG9yZWQgaW4NCiAgIHB1YmxpYyBjb25maWd1cmF0 aW9uIGZpbGVzLCBvciBvdGhlcndpc2UgdXNlZCBpbiBjbGVhciB0ZXh0LiAg Rm9yDQogICB0aGF0IHJlYXNvbiB0aGUgInBpbi12YWx1ZSIgYXR0cmlidXRl IHNob3VsZCBvbmx5IGJlIHVzZWQgaWYgdGhlIFVSSQ0KICAgc3RyaW5nIGl0 c2VsZiBpcyBwcm90ZWN0ZWQgd2l0aCB0aGUgc2FtZSBsZXZlbCBvZiBzZWN1 cml0eSBhcyB0aGUNCiAgIHRva2VuIFBJTiBieSBpdHNlbGYgb3RoZXJ3aXNl IGlzLg0KDQo3LiAgUmVmZXJlbmNlcw0KDQo3LjEuICBOb3JtYXRpdmUgUmVm ZXJlbmNlcw0KDQogICBbUkZDMzYyOV0gIFllcmdlYXUsIEYuLCAiVVRGLTgs IGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTw0KICAgICAgICAgICAg ICAxMDY0NiIsIFJGQyAzNjI5LCBTVEQgNjMsIE5vdmVtYmVyIDIwMDMuDQoN CiAgIFtSRkMzOTg2XSAgQmVybmVycy1MZWUsIFQuLCBGaWVsZGluZywgUi4s IGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0NCiAgICAgICAgICAgICAgUmVz b3VyY2UgSWRlbnRpZmllciAoVVJJKTogR2VuZXJpYyBTeW50YXgiLCBSRkMg Mzk4NiwgU1REDQogICAgICAgICAgICAgIDY2LCBKYW51YXJ5IDIwMDUuDQoN Cg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAgICAgRXhwaXJlcyBNYXJjaCAy NiwgMjAxNSAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBUaGUgUEtDUyMxMSBVUkkgU2NoZW1lICAgICAg ICAgICBTZXB0ZW1iZXIgMjAxNA0KDQoNCiAgIFtSRkM1MjM0XSAgQ3JvY2tl ciwgRC4gYW5kIFAuIE92ZXJlbGwsICJBdWdtZW50ZWQgQk5GIGZvciBTeW50 YXgNCiAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBSRkMg NTIzNCwgU1REIDY4LCBKYW51YXJ5IDIwMDguDQoNCjcuMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzQzOTVdICBIYW5zZW4sIFQuLCBI YXJkaWUsIFQuLCBhbmQgTC4gTWFzaW50ZXIsICJHdWlkZWxpbmVzIGFuZA0K ICAgICAgICAgICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlcyBmb3IgTmV3 IFVSSSBTY2hlbWVzIiwgUkZDIDQzOTUsDQogICAgICAgICAgICAgIEZlYnJ1 YXJ5IDIwMDYuDQoNCiAgIFtwa2NzMTFfc3BlY10NCiAgICAgICAgICAgICAg UlNBIExhYm9yYXRvcmllcywgIlBLQ1MgIzExOiBDcnlwdG9ncmFwaGljIFRv a2VuIEludGVyZmFjZQ0KICAgICAgICAgICAgICBTdGFuZGFyZCB2Mi4yMCIs IEp1bmUgMjAwNC4NCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEphbiBQ ZWNoYW5lYw0KICAgT3JhY2xlIENvcnBvcmF0aW9uDQogICA0MTgwIE5ldHdv cmsgQ2lyY2xlDQogICBTYW50YSBDbGFyYSAgQ0EgOTUwNTQNCiAgIFVTQQ0K DQogICBFbWFpbDogSmFuLlBlY2hhbmVjQE9yYWNsZS5DT00NCiAgIFVSSTog ICBodHRwOi8vd3d3Lm9yYWNsZS5jb20NCg0KDQogICBEYXJyZW4gSi4gTW9m ZmF0DQogICBPcmFjbGUgQ29ycG9yYXRpb24NCiAgIE9yYWNsZSBQYXJrd2F5 DQogICBUaGFtZXMgVmFsbGV5IFBhcmsNCiAgIFJlYWRpbmcgIFJHNiAxUkEN CiAgIFVLDQoNCiAgIEVtYWlsOiBEYXJyZW4uTW9mZmF0QE9yYWNsZS5DT00N CiAgIFVSSTogICBodHRwOi8vd3d3Lm9yYWNsZS5jb20NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQZWNoYW5lYyAmIE1vZmZhdCAgICAg ICAgRXhwaXJlcyBNYXJjaCAyNiwgMjAxNSAgICAgICAgICAgICAgICBbUGFn ZSAxNl0NCg== ---559023410-947435663-1411443172=:14810-- From nobody Tue Sep 23 07:00:03 2014 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 DBBA91A8033 for ; Tue, 23 Sep 2014 07:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 KTTq-23L0aYq for ; Tue, 23 Sep 2014 06:59:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 723D91A802E for ; Tue, 23 Sep 2014 06:59:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D4E51BE97 for ; Tue, 23 Sep 2014 14:59:58 +0100 (IST) 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 cDrIwurxyke1 for ; Tue, 23 Sep 2014 14:59:57 +0100 (IST) Received: from [109.125.29.200] (unknown [109.125.29.200]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF58EBE20 for ; Tue, 23 Sep 2014 14:59:56 +0100 (IST) Message-ID: <54217CD9.4030500@cs.tcd.ie> Date: Tue, 23 Sep 2014 14:59:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "saag@ietf.org" References: <54217C39.4030008@w3.org> In-Reply-To: <54217C39.4030008@w3.org> X-Forwarded-Message-Id: <54217C39.4030008@w3.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aWoyf1BB-3nAixUMY4u0wL_qgRY Subject: [saag] Fwd: Starting work on WebCrypto v.Next chartering 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, 23 Sep 2014 14:00:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI S. - -------- Forwarded Message -------- Subject: Starting work on WebCrypto v.Next chartering Resent-Date: Tue, 23 Sep 2014 13:57:24 +0000 Resent-From: public-web-security@w3.org Date: Tue, 23 Sep 2014 15:57:13 +0200 From: Harry Halpin To: public-web-security@w3.org Everyone, The W3C Advisory Committee (composed of representatives of W3C member companies) has been notified that chartering will begin. Our wonderful chair Virginie Galindo has set-up a wiki-page https://www.w3.org/Security/wiki/IG/webcryptonext_workshop Please start editing! If you don't have a W3C account to edit the wiki, you can get one here: http://www.w3.org/Help/Account/ After one week of discussion on this list to see if we can get consensus on the charter, we'll send out a draft final report of the Web Crypto v.Next workshop for comments, to be published the week following. cheers, harry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUIXzVAAoJEC88hzaAX42iERwH/A7+szudbbAa9mwX/ivyMvkn /XiB18QAxDdpAE4Fk4QjcEb5kvf/Xur911QMSCthp2+iSvbPuvkfU8j4KuPlrnJ8 jw1gVM7t7tTs7qzENZiFp3IJwxrrgjUL0VOv01K42rhmNQhDH0C4cYelMRjaKGMD of0rXuMBMF4MgvZ8RaM9a/KYXEpfTIFountB0l/5Jmm3Opkx37UBcU+kEEsygZ9H J9s6G7rzGUruj+eVwOHZ03TcQnX1llcbRe/LZhTCf0rXmvAHof3zP417fI0wvE6d tZy+jlqXGcuL9p8AN1s+tRi9jkS0N7HoRBVTOITNPB5b0nUXk1jmqgshlxLmoCI= =It0y -----END PGP SIGNATURE----- From nobody Tue Sep 23 23:24:20 2014 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 8F79D1A1AAF for ; Tue, 23 Sep 2014 23:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 0QzTPjBaGGWr for ; Tue, 23 Sep 2014 23:24:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 D70B11A02F5 for ; Tue, 23 Sep 2014 23:24:16 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8O6OF2b002350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 24 Sep 2014 02:24:15 -0400 Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8O6OB9o020606 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2014 02:24:13 -0400 Message-ID: <5422638B.1050305@redhat.com> Date: Wed, 24 Sep 2014 08:24:11 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Jan Pechanec References: <20140721175658.1086.20555.idtracker@ietfa.amsl.com> <53D25A83.2020607@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/VsLPmUbjlP1CBZb1U4MygE5HKps Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] nitpicks about draft-pechanec-pkcs11uri-14.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: Wed, 24 Sep 2014 06:24:18 -0000 On 23.9.2014 05:32, Jan Pechanec wrote: > On Fri, 25 Jul 2014, Jan Pechanec wrote: > >> On Fri, 25 Jul 2014, Petr Spacek wrote: >> >>> Hello, >> >> hi Petr, >> >>> I'm implementing draft-pechanec-pkcs11uri-14 for FreeIPA project and during >>> that work I have found two nits on draft-pechanec-pkcs11uri-14: >>> >>> On http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14#page-6: >>> >>> I would propose to split/reformulate the paragraph starting with: >>> "The path component attribute "token" represents a token label and corresponds >>> to the "label" member of the CK_TOKEN_INFO structure" ... >>> >>> The first sentence (enumeration) spans over 15 lines and I personally find it >>> difficult to read. Maybe a table would be better: >> <...> >> >> thanks for the feedback, it's much appreciated. I will see what >> I can do about this one. > > hello Petr, > > attached is a new working version of the draft, I plan to file > it within a few days. Does it address your comment? Aside from the > change that converted that long paragraph into a table, there are also a > couple of minor clarification changes unrelated to your feedback. Hello Jan, it is perfect, thank you! -- Petr Spacek @ Red Hat From nobody Thu Sep 25 10:58:13 2014 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 CBB881A01FA for ; Thu, 25 Sep 2014 10:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 S_b1Ukp0z8-T for ; Thu, 25 Sep 2014 10:58:10 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD0591A01C6 for ; Thu, 25 Sep 2014 10:58:10 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8PHw8MT030491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Sep 2014 17:58:09 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8PHw8Ix020111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2014 17:58:08 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8PHw8Ie001060; Thu, 25 Sep 2014 17:58:08 GMT Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Sep 2014 10:58:07 -0700 Date: Thu, 25 Sep 2014 10:58:06 -0700 (PDT) From: Jan Pechanec X-X-Sender: jpechane@keflavik To: Petr Spacek In-Reply-To: <5422638B.1050305@redhat.com> Message-ID: References: <20140721175658.1086.20555.idtracker@ietfa.amsl.com> <53D25A83.2020607@redhat.com> <5422638B.1050305@redhat.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/yUXovEPgL7ZatU-mtvC393uOur0 Cc: Darren.Moffat@oracle.com, saag@ietf.org Subject: Re: [saag] nitpicks about draft-pechanec-pkcs11uri-14.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: Thu, 25 Sep 2014 17:58:12 -0000 On Wed, 24 Sep 2014, Petr Spacek wrote: >> hello Petr, >> >> attached is a new working version of the draft, I plan to file >> it within a few days. Does it address your comment? Aside from the >> change that converted that long paragraph into a table, there are also a >> couple of minor clarification changes unrelated to your feedback. > > Hello Jan, > > it is perfect, thank you! Petr, glad to hear that, thanks. I've just filed it as a new draft. In a couple of weeks I will start working on last calling it. -- Jan Pechanec