From nobody Tue Jul 14 11:07:26 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D71AD2EE for ; Tue, 14 Jul 2015 11:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpQ9d5ZJPvAj for ; Tue, 14 Jul 2015 11:07:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FDA1AD357 for ; Tue, 14 Jul 2015 11:07:13 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB292.namprd03.prod.outlook.com (10.141.68.28) with Microsoft SMTP Server (TLS) id 15.1.213.14; Tue, 14 Jul 2015 18:07:12 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.01.0207.004; Tue, 14 Jul 2015 18:07:11 +0000 From: "Orit Levin (LCA)" To: Eliot Lear , "appsdir@ietf.org" Thread-Topic: [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts Thread-Index: AQHQr4DcT2qcK6DgvkiqLOtwc4J9zZ29oujwgBRIQaA= Date: Tue, 14 Jul 2015 18:07:11 +0000 Message-ID: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [109.65.137.173] x-microsoft-exchange-diagnostics: 1; BL2PR03MB292; 5:m42Kt6NxxA3Qx6D255lLIedqD7dlHEDi1bmlcY9uJO6zyveE9xriJzGXO9LVacY3eZLUI6uoBFrZbPcBRdfSOsm4vbWzps24v2Rxw14BuClyAssflVLKqlftWM2CZO0hzwqsM27bq3Q/ONfVmGVfTg==; 24:ALWZ1mont3OtDpCGYz6OCNQ1iT1j5Pe5VWS8YkkOV59x/Dilo3uj3LbnB5slf40V3N5UMDm/aEQltdhbTpel48wREobZ3cjCqU5UupP9GPQ=; 20:403E/pjC6aDYnEpRtn51NGPhqFOkQyDJPftZhI0qqKO2niyERFpRY9Q+Tzd3Ils7DkOHLB0oX0HFNHOG3Oz06Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB292; bl2pr03mb292: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB292; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB292; x-forefront-prvs: 0637FCE711 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(164054003)(51704005)(13464003)(2473001)(377454003)(24454002)(2501003)(106116001)(33656002)(2656002)(99286002)(5003600100002)(5001770100001)(86362001)(74316001)(76576001)(92566002)(87936001)(19580405001)(107886002)(50986999)(86612001)(66066001)(19580395003)(46102003)(77096005)(5001960100002)(102836002)(62966003)(40100003)(77156002)(5002640100001)(93886004)(2950100001)(189998001)(15975445007)(2900100001)(76176999)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB292; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2015 18:07:11.7075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB292 Archived-At: Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:07:25 -0000 Disclaimer: I am familiar with RTC and WebRTC, but I haven't followed the R= TCWeb work in the last few years. I read the two drafts for the first time. Therefore, my apologies for potentially raising points that have been discu= ssed in the past.=20 >From the APP (or ART) review perspective, my main comment is on the topic o= f "Web-Based Peer Authentication". While it is not clear from the text, whi= ch parts are already standardized concepts (e.g., by W3C) and which are int= roduced here for the first time, the described approach seems to be (1) use= ful to web applications beyond WebRTC, (2) under development and thus proba= bly not stable, and (3) too detailed for "an architecture" document. As su= ch, the concept of " Web-Based Peer Authentication" probably needs to be in= troduced and standardized under the Security Area and then adopted by WebRT= C and other apps. https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ This document contains an excellent collection of security threats to WebRT= C and discusses many different ideas for their potential mitigation. That b= eing said, it is not an easy read. Specifically, from high level to more sp= ecific: 1. The intended status of the document is Standards Track, while a typical = status of a "security threat model" RFC is Informational. This discrepancy = probably lies in the current scope of the document. See the next comment be= low. 2. The scope of the document is not clear. In addition to describing the se= curity threats (and the requirements or user expectations related to their = prevention), in many places the document lists potential solutions with the= ir perceived limitations and/or applicability. Examples are sections: 4.2.1= , 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To improve the document's= readability and reduce overlaps, the solutions should be introduced and e= xplained in the companion "architecture" document. Solutions' applicability= to different use cases needs to be provided in a non-bias way. 3. Apart from the brief Introduction with a few examples, there is no descr= iption of the WebRTC threat model putting all main types of threat in one p= lace. For example, the "Communications Security" aspect is introduced for t= he first time in Section 4.3 only. The start of Section "4. Security for We= bRTC Applications" could be a logical place for introducing the WebRTC thre= at model. 4. The "simple WebRTC system" presented in the Introduction in Figure 1 is = inadequate to illustrate many of the scenarios and points discussed in the = document. For example, see the discussion around media origin vs. web origi= n in Section 4.1.3. 5. Section "3. The Browser Threat Model" is an overview of the existing web= security architecture and some current practices. As such, references to r= elevant standards (e.g., W3C) and common practices need to be added within = the text to help the reader to understand the status of the information and= to follow the sources. 6. The last paragraph in Section 4.1 conveys a key point in the whole WebRT= C threat model. As such, it needs to be moved to the start of the discussi= on where the threat model is introduced (see comments above). 7. Stylistically, the document would benefit from removing non-standards vo= cabulary, i.e., "to bug", "to bug me", "no real way", "it is important to r= equire", "extremely aggressive intermediates", and "for obvious reasons", = etc. 8. Suggestions for renaming some of the sections to improve readability: "3. The Browser Threat Model" -> " 3. Overview of the Existing Web Threat M= odel" "4.1. Access to Local Devices" -> "4.1. Consent to Access Local Resources" "4.1.2. Calling Scenarios and User Expectations" -> "4.1.2. Scope of Consen= t in Various Calling Scenarios" "4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-term Consent" "4.1.2.2. Calling the site You're On" -> "4.1.2.2. Short-term Consent" "4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers and Origin-based Se= curity" "4.1.4. Security Properties of the Calling Page" -> "4.1.4. Network Attacke= rs and Security Properties of the Calling Page" "4.2. Communications Consent Verification" -> "4.2. Consent to Receive Traf= fic" "4.3.3. Malicious Peers" -> "4.3.3. Out of Scope" https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ This document is in a much better state in terms of its organization and re= adability. It introduces the security architecture using an example and the= n lists possible approaches to implement it. Some approaches are described = on a high level by referencing other documents, while others are introduced= for the first time in this document together with their implementation det= ails. By just reading the document, it is difficult to judge whether these = details are sufficient or stable enough for implementation. In general, I d= oubt that this is the best approach for an "architecture" document, which i= s supposed to serve as a long term stable reference. More specific comments: 1. Different terminology is used throughout the document to address same or= close concepts. It would help a lot to explain the concepts upfront and th= en to use the terminology consistently. Currently it includes "client", "en= dpoint", "peer", "user"; "implementation", "browser", "chrome", "API", "JS= "; "application", "server", etc. 2. The discussion is phrased in terms of "authentication" and "trust". In t= hink that "authorization" instead of "trust" would be a better technical te= rm, for example, in Section 3.1. 3. In section 4. Overview, sentence "the tension between security (or perfo= rmance) and privacy" is not clear, especially because it doesn't seem to co= rrespond to Section 6.2. (BTW "tradeoff" would be a better word than "tensi= on".) 4. Section "4.1. Initial Signaling", the text is inconsistent in terms of w= hether Alice and Bob share or use different identity providers. 5. Section "4.1. Initial Signaling", reference to PeerConnection needs to b= e added. 6. Section "4.2. Media Consent Verification" and Section "5.3 Communication= s Consent": the name/terminology of this functionality needs to be harmoniz= ed. The ICE-based solution with its pros, cons as well as the alternatives = (applicable to different use cases) need to be moved from the companion thr= eat model document to this "architecture" one. 7. A suggestion: rename "5. Detailed Technical Description" to "5. Security= Architecture Components". 8. In Section 5.2., "Implementations which support some form of direct user= authentication..." -> "Implementations that support some form of direct us= er authentication..." 9. Section "5.6. Web-Based Peer Authentication" and section "5.6.2. Overvie= w of operation": It is not clear, which parts are standardized concepts (e.= g., by W3C) and which are introduced here for the first time. If exist, ref= erences to existing standards need to be added. The described architecture = and the technical details seem to be (1) under development and thus probabl= y not stable, (2) too detailed for "an architecture" document and (3) usefu= l beyond WebRTC. As such, the concept of the " Web-Based Peer Authenticati= on" probably needs be introduced under the Security Area and then adopted b= y WebRTC. 10. The web-based peer authentication using IdP is not the only mechanism a= pplicable to WebRTC. Moreover, the web-based peer authentication is not th= e only approach applicable to WebRTC. Alternatives are listed in the compan= ion document and need to be moved here to the "architecture" document with = their pros and cons presented in an unbiased way. 11. Stylistically, the document would benefit from removing non-standards v= ocabulary, i.e., "some Web server", "can't really trust", "that much", "fai= rly conventional", "simply have", "a little anticlimactic", etc. ;-) Thanks, Orit. > -----Original Message----- > From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin > (LCA) > Sent: Thursday, June 25, 2015 1:17 PM > To: Eliot Lear; appsdir@ietf.org > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtcweb= - > security drafts >=20 > Perfect! I have a very long flight on the 7th... So right after then or e= arlier. > Orit. >=20 > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Thursday, June 25, 2015 12:55 PM > > To: Orit Levin (LCA); appsdir@ietf.org > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtcw= eb- > > security drafts > > > > Thank you Orit! Can you try to have them done in about two weeks? > > > > Eliot > > > > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote: > > > I will be happy to take a look at them! > > > Orit. > > > > > >> -----Original Message----- > > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot > Lear > > >> Sent: Thursday, June 25, 2015 11:44 AM > > >> To: appsdir@ietf.org > > >> Subject: [appsdir] Fwd: Request for Apps Directorate review of rtcwe= b- > > >> security drafts > > >> > > >> Dear Appsdir folk, > > >> > > >> Could I have a volunteer to review the following two drafts? > > >> > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > >> > > >> and > > >> > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > > >> > > >> Ted is exempt, having made the request ;-) > > >> > > >> Eliot > > >=20 > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir From nobody Tue Jul 14 11:18:35 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95761AD49B; Tue, 14 Jul 2015 11:18:31 -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 TbMReumkcvci; Tue, 14 Jul 2015 11:18:27 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6801AD2B2; Tue, 14 Jul 2015 11:18:25 -0700 (PDT) Received: by widjy10 with SMTP id jy10so107110686wid.1; Tue, 14 Jul 2015 11:18:24 -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=gNZws9RhcC4HkIpb4k9L2THRb7QVmtI9Al6uNBYjK3Q=; b=Ol4iNsHuNUO+B3CNruETUqYuEJTgGs2GFoa0OH+g7Pom8TU9GTLNIifFNK+1dSZdIc kV5w82IkEAR/edReBjES34Dezo2PhtJSsL2Cs4HFDy4Cn1j66gZKoS0FubbPTQb58B25 zt405fxu6ZZdzYm4RH1G5Uh16L4njEiyAlXRLRjE8jgL8NP0Uwy6UlKOUdqAAli1RUSg nNiECLh8eS3XUT4KoQs3Lgn99dMBtluX/97on6yCA8HaCW6MMKpRNjTOvvR9Xgmz3SsD kHaDAGSs/GEcvaEWhA/09dvns4LNpTWUDrd9oD+k7CaFzgmbAdxuejR5OL80tdE0gkQp ugMg== MIME-Version: 1.0 X-Received: by 10.180.80.138 with SMTP id r10mr7803328wix.18.1436897904660; Tue, 14 Jul 2015 11:18:24 -0700 (PDT) Received: by 10.194.17.68 with HTTP; Tue, 14 Jul 2015 11:18:24 -0700 (PDT) In-Reply-To: References: <558C4C02.3000404@cisco.com> <558C5CA3.7020108@cisco.com> Date: Tue, 14 Jul 2015 11:18:24 -0700 Message-ID: From: Ted Hardie To: "Orit Levin (LCA)" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444038a2f94a8051ad9dd9c Archived-At: Cc: "appsdir@ietf.org" , Eliot Lear Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtcweb-security drafts X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:18:31 -0000 --f46d0444038a2f94a8051ad9dd9c Content-Type: text/plain; charset=UTF-8 (adding the WG) Hi Orit, Thanks for the review. regards, Ted Hardie On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (LCA) wrote: > Disclaimer: I am familiar with RTC and WebRTC, but I haven't followed the > RTCWeb work in the last few years. I read the two drafts for the first time. > Therefore, my apologies for potentially raising points that have been > discussed in the past. > > >From the APP (or ART) review perspective, my main comment is on the topic > of "Web-Based Peer Authentication". While it is not clear from the text, > which parts are already standardized concepts (e.g., by W3C) and which are > introduced here for the first time, the described approach seems to be (1) > useful to web applications beyond WebRTC, (2) under development and thus > probably not stable, and (3) too detailed for "an architecture" document. > As such, the concept of " Web-Based Peer Authentication" probably needs to > be introduced and standardized under the Security Area and then adopted by > WebRTC and other apps. > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > This document contains an excellent collection of security threats to > WebRTC and discusses many different ideas for their potential mitigation. > That being said, it is not an easy read. Specifically, from high level to > more specific: > 1. The intended status of the document is Standards Track, while a typical > status of a "security threat model" RFC is Informational. This discrepancy > probably lies in the current scope of the document. See the next comment > below. > 2. The scope of the document is not clear. In addition to describing the > security threats (and the requirements or user expectations related to > their prevention), in many places the document lists potential solutions > with their perceived limitations and/or applicability. Examples are > sections: 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To improve > the document's readability and reduce overlaps, the solutions should be > introduced and explained in the companion "architecture" document. > Solutions' applicability to different use cases needs to be provided in a > non-bias way. > 3. Apart from the brief Introduction with a few examples, there is no > description of the WebRTC threat model putting all main types of threat in > one place. For example, the "Communications Security" aspect is introduced > for the first time in Section 4.3 only. The start of Section "4. Security > for WebRTC Applications" could be a logical place for introducing the > WebRTC threat model. > 4. The "simple WebRTC system" presented in the Introduction in Figure 1 is > inadequate to illustrate many of the scenarios and points discussed in the > document. For example, see the discussion around media origin vs. web > origin in Section 4.1.3. > 5. Section "3. The Browser Threat Model" is an overview of the existing > web security architecture and some current practices. As such, references > to relevant standards (e.g., W3C) and common practices need to be added > within the text to help the reader to understand the status of the > information and to follow the sources. > 6. The last paragraph in Section 4.1 conveys a key point in the whole > WebRTC threat model. As such, it needs to be moved to the start of the > discussion where the threat model is introduced (see comments above). > 7. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "to bug", "to bug me", "no real way", "it is important to > require", "extremely aggressive intermediates", and "for obvious reasons", > etc. > 8. Suggestions for renaming some of the sections to improve readability: > "3. The Browser Threat Model" -> " 3. Overview of the Existing Web Threat > Model" > "4.1. Access to Local Devices" -> "4.1. Consent to Access Local Resources" > "4.1.2. Calling Scenarios and User Expectations" -> "4.1.2. Scope of > Consent in Various Calling Scenarios" > "4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-term Consent" > "4.1.2.2. Calling the site You're On" -> "4.1.2.2. Short-term Consent" > "4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers and Origin-based > Security" > "4.1.4. Security Properties of the Calling Page" -> "4.1.4. Network > Attackers and Security Properties of the Calling Page" > "4.2. Communications Consent Verification" -> "4.2. Consent to Receive > Traffic" > "4.3.3. Malicious Peers" -> "4.3.3. Out of Scope" > > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > This document is in a much better state in terms of its organization and > readability. It introduces the security architecture using an example and > then lists possible approaches to implement it. Some approaches are > described on a high level by referencing other documents, while others are > introduced for the first time in this document together with their > implementation details. By just reading the document, it is difficult to > judge whether these details are sufficient or stable enough for > implementation. In general, I doubt that this is the best approach for an > "architecture" document, which is supposed to serve as a long term stable > reference. > More specific comments: > 1. Different terminology is used throughout the document to address same > or close concepts. It would help a lot to explain the concepts upfront and > then to use the terminology consistently. Currently it includes "client", > "endpoint", "peer", "user"; "implementation", "browser", "chrome", "API", > "JS"; "application", "server", etc. > 2. The discussion is phrased in terms of "authentication" and "trust". In > think that "authorization" instead of "trust" would be a better technical > term, for example, in Section 3.1. > 3. In section 4. Overview, sentence "the tension between security (or > performance) and privacy" is not clear, especially because it doesn't seem > to correspond to Section 6.2. (BTW "tradeoff" would be a better word than > "tension".) > 4. Section "4.1. Initial Signaling", the text is inconsistent in terms of > whether Alice and Bob share or use different identity providers. > 5. Section "4.1. Initial Signaling", reference to PeerConnection needs to > be added. > 6. Section "4.2. Media Consent Verification" and Section "5.3 > Communications Consent": the name/terminology of this functionality needs > to be harmonized. The ICE-based solution with its pros, cons as well as the > alternatives (applicable to different use cases) need to be moved from the > companion threat model document to this "architecture" one. > 7. A suggestion: rename "5. Detailed Technical Description" to "5. > Security Architecture Components". > 8. In Section 5.2., "Implementations which support some form of direct > user authentication..." -> "Implementations that support some form of > direct user authentication..." > 9. Section "5.6. Web-Based Peer Authentication" and section "5.6.2. > Overview of operation": It is not clear, which parts are standardized > concepts (e.g., by W3C) and which are introduced here for the first time. > If exist, references to existing standards need to be added. The described > architecture and the technical details seem to be (1) under development and > thus probably not stable, (2) too detailed for "an architecture" document > and (3) useful beyond WebRTC. As such, the concept of the " Web-Based Peer > Authentication" probably needs be introduced under the Security Area and > then adopted by WebRTC. > 10. The web-based peer authentication using IdP is not the only mechanism > applicable to WebRTC. Moreover, the web-based peer authentication is not > the only approach applicable to WebRTC. Alternatives are listed in the > companion document and need to be moved here to the "architecture" document > with their pros and cons presented in an unbiased way. > 11. Stylistically, the document would benefit from removing non-standards > vocabulary, i.e., "some Web server", "can't really trust", "that much", > "fairly conventional", "simply have", "a little anticlimactic", etc. ;-) > > Thanks, > Orit. > > > -----Original Message----- > > From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Orit Levin > > (LCA) > > Sent: Thursday, June 25, 2015 1:17 PM > > To: Eliot Lear; appsdir@ietf.org > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > security drafts > > > > Perfect! I have a very long flight on the 7th... So right after then or > earlier. > > Orit. > > > > > -----Original Message----- > > > From: Eliot Lear [mailto:lear@cisco.com] > > > Sent: Thursday, June 25, 2015 12:55 PM > > > To: Orit Levin (LCA); appsdir@ietf.org > > > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > security drafts > > > > > > Thank you Orit! Can you try to have them done in about two weeks? > > > > > > Eliot > > > > > > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote: > > > > I will be happy to take a look at them! > > > > Orit. > > > > > > > >> -----Original Message----- > > > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot > > Lear > > > >> Sent: Thursday, June 25, 2015 11:44 AM > > > >> To: appsdir@ietf.org > > > >> Subject: [appsdir] Fwd: Request for Apps Directorate review of > rtcweb- > > > >> security drafts > > > >> > > > >> Dear Appsdir folk, > > > >> > > > >> Could I have a volunteer to review the following two drafts? > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ > > > >> > > > >> and > > > >> > > > >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/ > > > >> > > > >> Ted is exempt, having made the request ;-) > > > >> > > > >> Eliot > > > > > > > _______________________________________________ > > appsdir mailing list > > appsdir@ietf.org > > https://www.ietf.org/mailman/listinfo/appsdir > > _______________________________________________ > appsdir mailing list > appsdir@ietf.org > https://www.ietf.org/mailman/listinfo/appsdir > --f46d0444038a2f94a8051ad9dd9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(adding the WG)

Hi Orit,<= br>
Thanks for the review.

regard= s,

Ted Hardie
On Tue, Jul 14, 2015 at 11:07 AM, Orit Levin (= LCA) <oritl@microsoft.com> wrote:
Disclaimer: I am familiar with RTC and WebRTC, but I haven't = followed the RTCWeb work in the last few years. I read the two drafts for t= he first time.
Therefore, my apologies for potentially raising points that have been discu= ssed in the past.

>From the APP (or ART) review perspective, my main comment is on the top= ic of "Web-Based Peer Authentication". While it is not clear from= the text, which parts are already standardized concepts (e.g., by W3C) and= which are introduced here for the first time, the described approach seems= to be (1) useful to web applications beyond WebRTC, (2) under development = and thus probably not stable, and (3) too detailed for "an architectur= e" document.=C2=A0 As such, the concept of " Web-Based Peer Authe= ntication" probably needs to be introduced and standardized under the = Security Area and then adopted by WebRTC and other apps.

https://datatracker.ietf.org/doc/draft-i= etf-rtcweb-security/
This document contains an excellent collection of security threats to WebRT= C and discusses many different ideas for their potential mitigation. That b= eing said, it is not an easy read. Specifically, from high level to more sp= ecific:
1. The intended status of the document is Standards Track, while a typical = status of a "security threat model" RFC is Informational. This di= screpancy probably lies in the current scope of the document. See the next = comment below.
2. The scope of the document is not clear. In addition to describing the se= curity threats (and the requirements or user expectations related to their = prevention), in many places the document lists potential solutions with the= ir perceived limitations and/or applicability. Examples are sections: 4.2.1= , 4.2.2, 4.2.3, 4.2.4, 4.3.2.1, 4.3.2.2, 4.3.2.3. To improve the document&#= 39;s readability and reduce overlaps,=C2=A0 the solutions should be introdu= ced and explained in the companion "architecture" document. Solut= ions' applicability to different use cases needs to be provided in a no= n-bias way.
3. Apart from the brief Introduction with a few examples, there is no descr= iption of the WebRTC threat model putting all main types of threat in one p= lace. For example, the "Communications Security" aspect is introd= uced for the first time in Section 4.3 only. The start of Section "4. = Security for WebRTC Applications" could be a logical place for introdu= cing the WebRTC threat model.
4. The "simple WebRTC system" presented in the Introduction in Fi= gure 1 is inadequate to illustrate many of the scenarios and points discuss= ed in the document. For example, see the discussion around media origin vs.= web origin in Section 4.1.3.
5. Section "3. The Browser Threat Model" is an overview of the ex= isting web security architecture and some current practices. As such, refer= ences to relevant standards (e.g., W3C) and common practices need to be add= ed within the text to help the reader to understand the status of the infor= mation and to follow the sources.
6. The last paragraph in Section 4.1 conveys a key point in the whole WebRT= C threat model. As such,=C2=A0 it needs to be moved to the start of the dis= cussion where the threat model is introduced (see comments above).
7. Stylistically, the document would benefit from removing non-standards vo= cabulary, i.e., "to bug", "to bug me", "no real wa= y", "it is important to require", "extremely aggressive= intermediates",=C2=A0 and "for obvious reasons", etc.
8. Suggestions for renaming some of the sections to improve readability: "3. The Browser Threat Model" -> " 3. Overview of the Exi= sting Web Threat Model"
"4.1. Access to Local Devices" -> "4.1. Consent to Access= Local Resources"
"4.1.2. Calling Scenarios and User Expectations" -> "4.1.= 2. Scope of Consent in Various Calling Scenarios"
"4.1.2.1. Dedicated Calling Services" -> "4.1.2.1. Long-t= erm Consent"
"4.1.2.2. Calling the site You're On" -> "4.1.2.2. Sh= ort-term Consent"
"4.1.3. Origin-Based Security" -> "4.1.3. Web Attackers a= nd Origin-based Security"
"4.1.4. Security Properties of the Calling Page" -> "4.1.= 4. Network Attackers and=C2=A0 Security Properties of the Calling Page"= ;
"4.2. Communications Consent Verification" -> "4.2. Conse= nt to Receive Traffic"
"4.3.3. Malicious Peers" -> "4.3.3. Out of Scope"
https://datatracker.ietf.org/doc/dr= aft-ietf-rtcweb-security-arch/
This document is in a much better state in terms of its organization and re= adability. It introduces the security architecture using an example and the= n lists possible approaches to implement it. Some approaches are described = on a high level by referencing other documents, while others are introduced= for the first time in this document together with their implementation det= ails. By just reading the document, it is difficult to judge whether these = details are sufficient or stable enough for implementation. In general, I d= oubt that this is the best approach for an "architecture" documen= t, which is supposed to serve as a long term stable reference.
More specific comments:
1. Different terminology is used throughout the document to address same or= close concepts. It would help a lot to explain the concepts upfront and th= en to use the terminology consistently. Currently it includes "client&= quot;, "endpoint",=C2=A0 "peer", "user"; &quo= t;implementation", "browser", "chrome", "API&= quot;, "JS"; "application", "server", etc. 2. The discussion is phrased in terms of "authentication" and &qu= ot;trust". In think that "authorization" instead of "tr= ust" would be a better technical term, for example, in Section 3.1. 3. In section 4. Overview, sentence "the tension between security (or = performance) and privacy" is not clear, especially because it doesn= 9;t seem to correspond to Section 6.2. (BTW "tradeoff" would be a= better word than "tension".)
4. Section "4.1. Initial Signaling", the text is inconsistent in = terms of whether Alice and Bob share or use different identity providers. 5. Section "4.1. Initial Signaling", reference to PeerConnection = needs to be added.
6. Section "4.2. Media Consent Verification" and Section "5.= 3 Communications Consent": the name/terminology of this functionality = needs to be harmonized. The ICE-based solution with its pros, cons as well = as the alternatives (applicable to different use cases) need to be moved fr= om the companion threat model document to this "architecture" one= .
7. A suggestion: rename "5. Detailed Technical Description" to &q= uot;5. Security Architecture Components".
8. In Section 5.2., "Implementations which support some form of direct= user authentication..." -> "Implementations that support some= form of direct user authentication..."
9. Section "5.6. Web-Based Peer Authentication" and section "= ;5.6.2. Overview of operation": It is not clear, which parts are stand= ardized concepts (e.g., by W3C) and which are introduced here for the first= time. If exist, references to existing standards need to be added. The des= cribed architecture and the technical details seem to be (1) under developm= ent and thus probably not stable, (2) too detailed for "an architectur= e" document and (3) useful beyond WebRTC.=C2=A0 As such, the concept o= f the " Web-Based Peer Authentication" probably needs be introduc= ed under the Security Area and then adopted by WebRTC.
10. The web-based peer authentication using IdP is not the only mechanism a= pplicable to WebRTC. Moreover, the web-based peer authentication=C2=A0 is n= ot the only approach applicable to WebRTC. Alternatives are listed in the c= ompanion document and need to be moved here to the "architecture"= document with their pros and cons presented in an unbiased way.
11. Stylistically, the document would benefit from removing non-standards v= ocabulary, i.e., "some Web server", "can't really trust&= quot;, "that much", "fairly conventional", "simply= have", "a little anticlimactic", etc. ;-)

Thanks,
Orit.

> -----Original Message-----
> From: appsdir [mailto:apps= dir-bounces@ietf.org] On Behalf Of Orit Levin
> (LCA)
> Sent: Thursday, June 25, 2015 1:17 PM
> To: Eliot Lear; appsdir@ietf.org
> Subject: Re: [appsdir] Fwd: Request for Apps Directorate review of rtc= web-
> security drafts
>
> Perfect! I have a very long flight on the 7th... So right after then o= r earlier.
> Orit.
>
> > -----Original Message-----
> > From: Eliot Lear [mailto:lear@c= isco.com]
> > Sent: Thursday, June 25, 2015 12:55 PM
> > To: Orit Levin (LCA); appsdir= @ietf.org
> > Subject: Re: [appsdir] Fwd: Request for Apps Directorate review o= f rtcweb-
> > security drafts
> >
> > Thank you Orit!=C2=A0 Can you try to have them done in about two = weeks?
> >
> > Eliot
> >
> > On 6/25/15 9:52 PM, Orit Levin (LCA) wrote:
> > > I will be happy to take a look at them!
> > > Orit.
> > >
> > >> -----Original Message-----
> > >> From: appsdir [mailto:appsdir-bounces@ietf.org] On Behalf Of Eliot
> Lear
> > >> Sent: Thursday, June 25, 2015 11:44 AM
> > >> To: appsdir@ietf.org=
> > >> Subject: [appsdir] Fwd: Request for Apps Directorate rev= iew of rtcweb-
> > >> security drafts
> > >>
> > >> Dear Appsdir folk,
> > >>
> > >> Could I have a volunteer to review the following two dra= fts?
> > >>
> > >> https://datatracker.i= etf.org/doc/draft-ietf-rtcweb-security/
> > >>
> > >> and
> > >>
> > >> https://datatrac= ker.ietf.org/doc/draft-ietf-rtcweb-security-arch/
> > >>
> > >> Ted is exempt, having made the request ;-)
> > >>
> > >> Eliot
> >
>
> _______________________________________________
> appsdir mailing list
> appsdir@ietf.org
> https://www.ietf.org/mailman/listinfo/appsdir<= br>
_______________________________________________
appsdir mailing list
appsdir@ietf.org
https://www.ietf.org/mailman/listinfo/appsdir

--f46d0444038a2f94a8051ad9dd9c-- From nobody Sun Jul 19 02:01:02 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FE91A8992 for ; Sun, 19 Jul 2015 02:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9KPPrnpXzy3 for ; Sun, 19 Jul 2015 02:00:58 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A360B1A8820 for ; Sun, 19 Jul 2015 02:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1043; q=dns/txt; s=iport; t=1437296457; x=1438506057; h=to:from:subject:message-id:date:mime-version; bh=wjTWALivQQjpEpWxB0b8Tt4bOBY1YGimc3hsEKk6/NI=; b=V8++n0uolDDKHD6O7szG5mv/oOlnaMeSmRioHmNa12FYojfuGQ49FQw6 UmLLd05n0zPM5+k5tjB+OClK84t51sCTzp39RBBV4usWYLXXmCYI0roye DmrQuEgfrX/jVSgvvVSVwA4wPTIpHN714yVSfPYunFWztwHhbiXS0kd5g A=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4BADnZatV/xbLJq1bh3PCIgEBAQEBAYELhE1VPRYLAgsDAgECAUsNCAEBiCqlSY9flS8BAQEHAgEfi0yHdYFDAQSUUoIzgVSIGohLkDwmg348gnwBAQE X-IronPort-AV: E=Sophos;i="5.15,502,1432598400"; d="asc'?scan'208";a="567931245" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Jul 2015 09:00:55 +0000 Received: from [10.61.90.21] (ams3-vpn-dhcp6678.cisco.com [10.61.90.21]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6J90tSD016889 for ; Sun, 19 Jul 2015 09:00:55 GMT To: "appsdir@ietf.org" From: Eliot Lear Message-ID: <55AB674C.9070103@cisco.com> Date: Sun, 19 Jul 2015 11:01:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SPxt4b7Vowf31EMPXuAeQVm1aBOc1sKsQ" Archived-At: Subject: [appsdir] review request: draft-iab-crypto-alg-agility X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 09:01:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SPxt4b7Vowf31EMPXuAeQVm1aBOc1sKsQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear friends, Would someone mind reviewing this document in the next two-three weeks? Thanks, Eliot --SPxt4b7Vowf31EMPXuAeQVm1aBOc1sKsQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVq2dMAAoJEIe2a0bZ0noz1oMH/21z23NApHqLaxDv8v8jJvc0 aOwaMyZM+p8lnzsAL/eLUfF3Ym1KuEAT3f86McCi/IGABAj6qauvJLDmp7Xu3znD 9FzaK7I6vEiRhjY/t7tyei8GXsJ5XMUAZBmnoAVDs1YyyU0WCQ051aHYB+UjlG3u L3QQ94TsPaDkQ/PR/5IXOJRHJbB9Xsj9CJ40NcLQDRKDWkzXx8SHpGO4qA2460e2 E3eIS+8qdj1oakQiHpSq3Bb0QmJXIDU5dDa3WtM8IPiNSIK5DCtuB3uNwlUCP5Qu m5IwtL6ynA8HswO8U9jXUKSR3W9I7i+43+7YPl3kmhURF2+xH16ibnAWBQOfwuY= =HZO9 -----END PGP SIGNATURE----- --SPxt4b7Vowf31EMPXuAeQVm1aBOc1sKsQ-- From nobody Fri Jul 24 01:33:28 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9941A1AB2 for ; Fri, 24 Jul 2015 01:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mhRr_s6V9jEm for ; Fri, 24 Jul 2015 01:33:26 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226DC1A1A11 for ; Fri, 24 Jul 2015 01:33:22 -0700 (PDT) Received: by iggf3 with SMTP id f3so11202773igg.1 for ; Fri, 24 Jul 2015 01:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O+bbLi5q2qEBKtclHelhyLs9Laegcbken6k2Afs/rpc=; b=Ie1OS0j/t8LVkcJmdGPxV38m/oTfr7pGaajbD1eco6u4j+tOYeZzoVXndzxC5RtHan Lib206Hh9F3GRfVJQids2PiGQ6sQrABm9TnEeccLXp4d3knuPILuQ2u34Gvo+oCtTD8+ kd85qZ7+adZSq9q5DRA/1vPeXuNLUAAEPMHUQO4jCDZmKkxm+vO/Fr/ZKifSvD7mk7Ix xyvSCsNP1CkK3aP0Xpg4SikkHDMNere9CkOnvQkWmX5v2hlFrXekogEfVGiCMd24LukH U5DNsFQmd0o28Gm3rNvPjbZ4d/v+L7SRq4nCaXOc4BAAEnSITyu9uL5GsNI52CGwtd2n zPkg== MIME-Version: 1.0 X-Received: by 10.50.111.231 with SMTP id il7mr3839669igb.23.1437726801623; Fri, 24 Jul 2015 01:33:21 -0700 (PDT) Received: by 10.107.133.200 with HTTP; Fri, 24 Jul 2015 01:33:21 -0700 (PDT) Date: Fri, 24 Jul 2015 10:33:21 +0200 Message-ID: From: "Murray S. Kucherawy" To: "appsdir@ietf.org" Content-Type: multipart/alternative; boundary=047d7b4142c84b93bf051b9adb55 Archived-At: Subject: [appsdir] Cultivating I18N expertise X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:33:27 -0000 --047d7b4142c84b93bf051b9adb55 Content-Type: text/plain; charset=UTF-8 Some recent work that has passed through APPS, and APPSAWG in particular, has been in need of reviews specifically geared toward proper coverage of internationalization. There's been talk of considering creation of an I18N directorate since that's an important aspect of recent applications work without enough diligent review and focused expertise. I just chatted with Barry about it, and we think it might be simpler to just pay special attention to cultivating and focusing that expertise through APPSDIR rather than making a new directorate. We definitely ought to do one or the other though. Thoughts? -MSK --047d7b4142c84b93bf051b9adb55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some recent work that has passed through APPS, a= nd APPSAWG in particular, has been in need of reviews specifically geared t= oward proper coverage of internationalization.

There's bee= n talk of considering creation of an I18N directorate since that's an i= mportant aspect of recent applications work without enough diligent review = and focused expertise.=C2=A0 I just chatted with Barry about it, and we thi= nk it might be simpler to just pay special attention to cultivating and foc= using that expertise through APPSDIR rather than making a new directorate.= =C2=A0 We definitely ought to do one or the other though.

Thoughts?

-MSK
--047d7b4142c84b93bf051b9adb55-- From nobody Fri Jul 24 01:41:29 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C003A1A0AF7 for ; Fri, 24 Jul 2015 01:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCSjq2XEIkN3 for ; Fri, 24 Jul 2015 01:41:26 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C203E1A0231 for ; Fri, 24 Jul 2015 01:41:17 -0700 (PDT) Received: internal info suppressed Date: Fri, 24 Jul 2015 10:40:59 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1437727264; bh=IRw3piPpmMJUn+5zJQcQ7J7HH4/ejvm9R8KCrXYX9PE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eXa6TN0yrryp/I2iD1RIYjmUhAVD8S/2lfRO111PPKvvtF9TfulF/dxprca0f9BVQ 2q7Z0JqE/TWeV6LIdZYBpWreRxGxYqTNuWFDhMMeAoOqktkvQoewr57bUmEg1A3YY4 rOLpHvAYrPE7Q7hJbtYblmAV54+GQMXEwPCWt06g= Archived-At: Cc: "appsdir@ietf.org" Subject: Re: [appsdir] Cultivating I18N expertise X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:41:28 -0000 On Fri, 24 Jul 2015, Murray S. Kucherawy wrote: > Some recent work that has passed through APPS, and APPSAWG in particular, > has been in need of reviews specifically geared toward proper coverage of > internationalization. > > There's been talk of considering creation of an I18N directorate since > that's an important aspect of recent applications work without enough > diligent review and focused expertise. I just chatted with Barry about it, > and we think it might be simpler to just pay special attention to > cultivating and focusing that expertise through APPSDIR rather than making > a new directorate. We definitely ought to do one or the other though. > > Thoughts? I fully agree... keep it inside APPSDIR where most of the experts in the are are anyhow, and let's try to bring in also those who still are not here. I tried also to do this action, not easy, but we can try it again. For example we miss one of the known experts in the area: Harald Alvestrand - but he of course is quite busy... just to give one name. A "separate" directorate is a bad idea because then it needs liaisons to APPSDIR, and will not be efficient. (my 1 cent) > > -MSK > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; http://www.cert.garr.it/pgp/garr-cert-pgp-keys From nobody Fri Jul 24 02:13:45 2015 Return-Path: X-Original-To: appsdir@ietfa.amsl.com Delivered-To: appsdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFBC1A8737 for ; Fri, 24 Jul 2015 02:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfV3p6UHdAcE for ; Fri, 24 Jul 2015 02:02:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFC31A6EE7 for ; Fri, 24 Jul 2015 02:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1762; q=dns/txt; s=iport; t=1437728569; x=1438938169; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lSzHFdo5WLe0UMhoLyq4fPgB/DJWYulCuu3bkoiRW/c=; b=afFAP4kJrC8QaMmGJuKX9rqJZoKT7zFYuHbv1Z7WM15Hn1gYiL17gviZ kWrXaCm34m6ePYWrPVpzE7lsFWKqAae16Y5Lt3sJ1KDfJwPTZG8FZa3RD 13I4OVrZjMEY7AufXp5bqe9RRjHGcIcdbDzdjO/BAJ3HTNBBluoNfAcRO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqBQBo/rFV/5xdJa1cgxVUaQaDHbpbhTdKAhyBJzsRAQEBAQEBAYEKhCQBAQQjETceAgEIGgImAgICHxEVEAIEARKIGQMSDbQvkFINhS8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEiiiuCToIGOoJpL4EUBYUjj0ABig5DgWoBgUSEHYwYhyomg31vgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,537,1432598400"; d="scan'208";a="12704757" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jul 2015 09:02:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6O92X9d024612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jul 2015 09:02:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 04:02:32 -0500 From: "Joe Hildebrand (jhildebr)" To: "Murray S. Kucherawy" , "appsdir@ietf.org" Thread-Topic: [appsdir] Cultivating I18N expertise Thread-Index: AQHQxeuREksJSWNP3kyYfQX3bohmQp3qyG6A Date: Fri, 24 Jul 2015 09:02:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [10.61.67.84] Content-Type: text/plain; charset="utf-8" Content-ID: <8B1D52A326E68B48B7BB4502431822B3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 02:13:41 -0700 Subject: Re: [appsdir] Cultivating I18N expertise X-BeenThere: appsdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:02:51 -0000 T24gNy8yNC8xNSwgMTA6MzMgQU0sICJhcHBzZGlyIG9uIGJlaGFsZiBvZiBNdXJyYXkgUy4gS3Vj aGVyYXd5IiA8YXBwc2Rpci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdXBlcnVzZXJA Z21haWwuY29tPiB3cm90ZToNCg0KPlNvbWUgcmVjZW50IHdvcmsgdGhhdCBoYXMgcGFzc2VkIHRo cm91Z2ggQVBQUywgYW5kIEFQUFNBV0cgaW4gcGFydGljdWxhciwgaGFzIGJlZW4gaW4gbmVlZCBv ZiByZXZpZXdzIHNwZWNpZmljYWxseSBnZWFyZWQgdG93YXJkIHByb3BlciBjb3ZlcmFnZSBvZiBp bnRlcm5hdGlvbmFsaXphdGlvbi4NCj4NCj5UaGVyZSdzIGJlZW4gdGFsayBvZiBjb25zaWRlcmlu ZyBjcmVhdGlvbiBvZiBhbiBJMThOIGRpcmVjdG9yYXRlIHNpbmNlIHRoYXQncyBhbiBpbXBvcnRh bnQgYXNwZWN0IG9mIHJlY2VudCBhcHBsaWNhdGlvbnMgd29yayB3aXRob3V0IGVub3VnaCBkaWxp Z2VudCByZXZpZXcgYW5kIGZvY3VzZWQgZXhwZXJ0aXNlLiAgSSBqdXN0IGNoYXR0ZWQgd2l0aCBC YXJyeSBhYm91dCBpdCwgYW5kIHdlIHRoaW5rIGl0IG1pZ2h0IGJlIHNpbXBsZXIgdG8ganVzdA0K PiBwYXkgc3BlY2lhbCBhdHRlbnRpb24gdG8gY3VsdGl2YXRpbmcgYW5kIGZvY3VzaW5nIHRoYXQg ZXhwZXJ0aXNlIHRocm91Z2ggQVBQU0RJUiByYXRoZXIgdGhhbiBtYWtpbmcgYSBuZXcgZGlyZWN0 b3JhdGUuICBXZSBkZWZpbml0ZWx5IG91Z2h0IHRvIGRvIG9uZSBvciB0aGUgb3RoZXIgdGhvdWdo Lg0KPg0KPlRob3VnaHRzPw0KDQpXZSBhbHNvIGhhdmUgdGhlIElBQiBJMThuIHByb2dyYW0gKGh0 dHBzOi8vd3d3LmlhYi5vcmcvYWN0aXZpdGllcy9wcm9ncmFtcy9pbnRlcm5hdGlvbmFsaXphdGlv bi1wcm9ncmFtLyksIHdoaWNoIEkgbGVhZCBhdCB0aGUgbW9tZW50LiAgSWYgdGhlcmUgYXJlIG90 aGVycyB3aXRoIGludGVyZXN0IGluIGkxOG4tcmVsYXRlZCB0b3BpY3MsIHBsZWFzZSBzZW5kIG1l IGEgbWVzc2FnZSBvZmZsaW5lIHRvIGV4cGxvcmUgaG93IHlvdSBjYW4gaGVscC4gIFdlIHJlYWxs eSBuZWVkIGZvbGtzIHdpdGggY2x1ZSBhbmQgZW5lcmd5IHRvIHBpdGNoIGluIGlmIHdlIHdhbnQg dGhlIEludGVybmV0IHRvIGNvbnRpbnVlIHRvIGdldCBiZXR0ZXIgZm9yIGEgZGl2ZXJzZSBzZXQg b2YgdXNlcnMuDQoNCklmIHRoZXJlIGFyZSBkb2N1bWVudHMgeW91IG5lZWQgaGVscCB3aXRoLCBm ZWVsIGZyZWUgdG8gYXNrIHRoZSBwcm9ncmFtLCBhbmQgd2UnbGwgc2VlIHdoYXQgd2UgY2FuIGRv Lg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo=