From nobody Mon Nov 3 11:42:05 2014 Return-Path: X-Original-To: mcic@ietfa.amsl.com Delivered-To: mcic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBB51A7012; Mon, 3 Nov 2014 10:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52kdYI6B6Mcj; Mon, 3 Nov 2014 10:43:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0E81A6FCE; Mon, 3 Nov 2014 10:43:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141103184305.22298.82388.idtracker@ietfa.amsl.com> Date: Mon, 03 Nov 2014 10:43:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/mcic/w20XM6QRFzFyIYkj0XSi-y_nGns X-Mailman-Approved-At: Mon, 03 Nov 2014 11:41:55 -0800 Cc: salvatore.loreto@ericsson.com, mcic@ietf.org Subject: [Mcic] New Non-WG Mailing List: Mcic -- Multiparty Content Integrity and Confidentiality X-BeenThere: mcic@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "MCIC \(Multiparty Content Integrity and Confidentiality\) > " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 18:43:08 -0000 A new IETF non-working group email list has been created. List address: mcic@ietf.org Archive: http://www.ietf.org/mail-archive/web/mcic/ To subscribe: https://www.ietf.org/mailman/listinfo/mcic Purpose: The aim of this group it do design an object security architecture able to provide a better security but also more flexible security services than strict end-to-end encryption. An architecture content owner should be able to express what security levels different objects should be associated with. There are several ways to design an architecture that fulfills these requirements. All the alternatives have to be explored and discussed in order to understand the pro and cons. An important question to analyze is whether an object security architecture should be designed at the application layer (as a complementary solution to TLS) or further down the stack as a better alternative to TLS. For additional information, please contact the list administrators. From nobody Tue Nov 4 10:56:25 2014 Return-Path: X-Original-To: mcic@ietfa.amsl.com Delivered-To: mcic@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26201A7017 for ; Tue, 4 Nov 2014 10:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtgFXk-4FUJJ for ; Tue, 4 Nov 2014 10:54:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AC7D1A6F9F for ; Tue, 4 Nov 2014 10:54:39 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-76-545920ec1128 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EE.46.04081.CE029545; Tue, 4 Nov 2014 19:54:36 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.73]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 19:54:36 +0100 From: Salvatore Loreto To: Greg Wilkins , Mark Nottingham , "Simone Bordet" , Larry Masinter , "Barry Leiba" , Pete Resnick , Stephen Farrell , Jari Arkko , "Kathleen.Moriarty.ietf@gmail.com" , Alissa Cooper , Richard Barnes , Sean Turner , "joe@salowey.net" , "hannes.tschofenig@gmx.net" , "fielding@gbiv.com" , "kolkman@isoc.org" , "allison.mankin@gmail.com" , "ynir.ietf@gmail.com" , "J.deBorst@F5.com" , Peter Saint-Andre , "Joe Hildebrand (jhildebr)" , "emile.stephan@orange.com" , "Brian Raymor (MS OPEN TECH)" , Gabriel Montenegro , Rob Trace , Roberto Peon , Martin Nilsson , "Eric Rescorla" , Martin Thomson , "dmitry.anipko@microsoft.com" , Craig Taylor , Mike Jones , "Simon Pietro Romano" Thread-Topic: Web Obj Security bar BoF - Sunday Nov 9th Thread-Index: AQHP+GDGo+SEqCaVVke0/uHUhwEkWg== Date: Tue, 4 Nov 2014 18:54:34 +0000 Message-ID: <2770FB71-B99B-4B92-B78A-9EE336EE9C16@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_2770FB71B99B4B92B78A9EE336EE9C16ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed7rWglvmvVkELWCoIstizqhqfnppYhuQlZErXpRyWbsVTOK 8FYfnNrSMly2tC1ZMrNNXY402wotWXaBVpjlbWazIBMvmaipr4Hffuec3/k/58MjI/09dJAs Xp0kaNSqBAUjp4pixi9t+LnicLRyaCQMbrnHEXzUDhPgMr6nod3QRcAjexUCpzmTAPOPFhac DX8omMxRgsG+F5qKrCTocr9RcN/xlYbiv5ksvK5rYsFua2AhzZEID3+VsOBxTyCYaNOR0Fbz FEF94QAFlQPdCK6ZrAy8zfIxcDNvBzwY1zLQP+IjwH71Ewm36j0sNNZdI6G2RTf1QmM/EbmS LxzNIfmOKjPD3xiz0nxWeS7JD3p9BF+h/cDwprv1BG9pz2N5h/4LyxttDQxfYkvm24r7ad5k GiX4yZ5ili+w6im+rzCd3rf0iDzstJAQnyJoNoafkMe5vSPkufu7Uss62TRk2JGN5skwtwW/ HDQTEi/Gb79WMtlILvPnXiDc1epAUnEP4VKdm5m2GG4r7u2sJqcHi7iK+XiovpKcHpDcKny7 z0NPcwC3Gd8Zts7ELuIAj7V6SImDsc6hm+lT3Gr8+3r+DPtxEfhxV/qMg6bOGGm2EFLmEtzq vTt7HodNdW9IiQOxr3uClliB001eWvJPYW1zBiNlLsSviryUDgXo50Tp52j6OZrUX49Lngww Eq/DZaU/yP/sftY9uxuKJ50F1FynBMnKUaAoiCfPxoaEBAua+FOimKgOVgtJNjT1EZ3VY8pa 5Ovd6UKcDCkW+Cl3xkT706oU8cJZF1omoxRL/EpbDAf9uVhVknBGEM4JmuOa5ARBdCFCNi8o DQWO2lwdEY7lNevjatJ+HhpM2h1aOR6aM7x1+5qVn2MPVqmbFFeOnrwQvsVYVv7cndVrT3Qf qAjpiGr8vi/mjdwZnR/VVnzi8p93nyxKg/FMbdH+gtSAz8HVR8xx503bjzVs67mdp33frN7c bsygulrWRloSX/Zd7A/sSY+9I+Za6D0KSoxTbVpLakTVP8p2whNpAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/mcic/VtK5yjbLcezpRLXDhT5ufn8sUIQ X-Mailman-Approved-At: Tue, 04 Nov 2014 10:56:23 -0800 Cc: "mcic@ietf.org" Subject: [Mcic] Web Obj Security bar BoF - Sunday Nov 9th X-BeenThere: mcic@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "MCIC \(Multiparty Content Integrity and Confidentiality\) > " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 18:54:46 -0000 --_000_2770FB71B99B4B92B78A9EE336EE9C16ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Aloha, While you are getting ready for your next surfing adventure in the clear wa= ters of Hawaii, an invisible shark is lurking ready to attack again. This is not a joke. Pervasive monitoring is a threat and an attack as it ha= s been clearly identified and articulated in RFC 7258( https://tools.ietf.o= rg/html/rfc7258 )by the IETF community. It is a threat for individuals as i= t invades their privacy and a threat for organizations as it erodes their c= redibility in front of their customer constituency. It is a threat to the s= ociety as it challenges and inhibits the very basic rights like freedom of = expression. We must stop it and it is in our power to act by providing the = next generations' internet users with tools that make unlawful monitoring d= ifficult if not impossible. Our role in the IETF community is to evolve the= internet protocols in order to adapt to the society requirements and to fe= nd off the new (or old) threats. We live in a digital world where everythin= g we do and everything we say is one way or another captured, stored and sh= ared in electronic format. The Internet plays a central role in our lives, = our work and our social activities. It helps us connect, be informed and it= has already shown us the potential to topple oppressive governments as it = happened in Egypt or to fund non-profit causes as it was the case for Ice = Bucket challenge. The IETF community rallied behind the commitment to improve and enforce bet= ter security in the protocols we develop to preserve and protect the privac= y of the internet users, to regain their trust in an internet for everyone.= We all got excited about this objective and while existing protocols like = TLS, support strong client server e2e encryption they fail short at allowin= g more complex internet delivery methods to be implemented and deployed. Fr= om content distribution networks to interconnected web of things we are loo= king at a very sophisticated mesh where connections are optimized and enhan= ced by specialized intermediaries that improve efficiency and quality of ex= perience. In fact RFC 7258 acknowledges that certain forms of monitoring li= ke network management functions are necessary and should not be considered = attacks. On this premise, a few of us thought it would be useful to have a dialogue = about the challenges we are faced in deploying e2e encryption over the inte= rnet, the use cases that require multi party negotiation for content integr= ity and confidentiality and the requirements for intermediary aware protoco= ls and applications. This informal session will try to identify the problem, scope the use cases= , analyze existing solutions, present a few new proposals and most importan= tly facilitate the dialogue about the next steps we should take in order to= accomplish our goals of building better and more secure protocols for the = internet. We compiled a short draft http://www.ietf.org/internet-drafts/draft-reschke= -objsec-00.txt that attempts to touch some of the topics but it should only= serve as a starting point for a more engaged dialogue that we expect to ha= ve during the bar bof session. We have reserved Coral 2 room from 16:00 to 18:00 on Sunday Nov 9th and we = hope to see you there. Your RSVP is kindly requested in order to better plan for the session. This is an open invitation so feel free to forward this to anybody that mig= ht be interested in contributing to the discussion and can bring additional= use cases or security considerations to the table. The right venue to discuss the draft and/or to send any question related to= the topic is the MCIC (Multiparty Content Integrity and Confidentiality) non wg mailing list. You can subscribe here: https://www.ietf.org/mailman/listinfo/mcic We are aware about the overlap with the newcomers meeting and while we unde= rstand that some of you might have obligations to be there, we hope that yo= u can stop by and share some thoughts with us on this important topic. Looking forward to hearing from you. Best Regards, Dan Druta, Salvatore Loreto --_000_2770FB71B99B4B92B78A9EE336EE9C16ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <226BF1413A6085419642FDB9D50121EF@ericsson.com> Content-Transfer-Encoding: quoted-printable Aloha,

While you are getting ready for your next surfing adventure in the clear wa= ters of Hawaii, an invisible shark is lurking ready to attack again.
This is not a joke. Pervasive monitoring is a threat and an attack as it ha= s been clearly identified and articulated in RFC 7258( https://tools.ietf.org/html/rfc7258&nb= sp;)by the IETF community. It is a threat for individuals as it invades their privacy and a threat for organizations as = it erodes their credibility in front of their customer constituency. It is = a threat to the society as it challenges and inhibits the very basic rights= like freedom of expression. We must stop it and it is in our power to act by providing the next generatio= ns' internet users with tools that make unlawful monitoring difficult if no= t impossible. Our role in the IETF community is to evolve the internet prot= ocols in order to adapt to the society requirements and to fend off the new (or old) threats. We live in a digita= l world where everything we do and everything we say is one way or another = captured, stored and shared in electronic format. The Internet plays a cent= ral role in our lives, our work and our social activities. It helps us connect, be informed and it has alr= eady shown us the potential to topple oppressive governments as it happened=  in Egypt or to fund non-profit causes as it was the case for Ice Buc= ket challenge.

The IETF community rallied behind the commitment to improve and enforce bet= ter security in the protocols we develop to preserve and protect the privac= y of the internet users, to regain their trust in an internet for everyone.= We all got excited about this objective and while existing protocols like TLS, support strong client server e2e en= cryption they fail short at allowing more complex internet delivery methods= to be implemented and deployed. From content distribution networks to inte= rconnected web of things we are looking at a very sophisticated mesh where connections are optimized and e= nhanced by specialized intermediaries that improve efficiency and quality o= f experience. In fact RFC 7258 acknowledges that certain forms of monitorin= g like network management functions are necessary and should not be considered attacks.

On this premise, a few of us thought it would be useful to have a dialogue = about the challenges we are faced in deploying e2e encryption over the inte= rnet, the use cases that require multi party negotiation for content integr= ity and confidentiality and the requirements for intermediary aware protocols and applications.
This informal session will try to identify the problem, scope the use cases= , analyze existing solutions, present a few new proposals and most importan= tly facilitate the dialogue about the next steps we should take in order to= accomplish our goals of building better and more secure protocols for the internet.
We compiled a short draft http://www.ietf.org/internet-drafts/draft-r= eschke-objsec-00.txt that attempts to touch some of the topics but= it should only serve as a starting point for a more engaged dialogue that we expect to have during the bar bof session.


We have reserved Coral 2 room from 16:00 to 18:00 on Sunday Nov 9th and we = hope to see you there. 
Your RSVP is kindly requested in order to better plan for the session.=


This is an open invitation so feel free to forward this to anybody that mig= ht be interested in contributing to the discussion and can bring additional= use cases or security considerations to the table.


The right venue to discuss the draft and/or to send any question relat= ed to the topic is the MCIC (Multiparty Content Integrity and Confiden= tiality)
non wg mailing list. 


We are aware about the overlap with the newcomers meeting and while we unde= rstand that some of you might have obligations to be there, we hope that yo= u can stop by and share some thoughts with us on this important topic.

Looking forward to hearing from you.

Best Regards,
Dan Druta, Salvatore Loreto
--_000_2770FB71B99B4B92B78A9EE336EE9C16ericssoncom_--