[Mcic] Summary + Next Steps from Web Obj Security bar BoF - Sunday Nov 9th

"Klas, Guenter, Vodafone Group" <Guenter.Klas@vodafone.com> Mon, 01 December 2014 19:12 UTC

Return-Path: <Guenter.Klas@vodafone.com>
X-Original-To: mcic@ietfa.amsl.com
Delivered-To: mcic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6139A1A8986 for <mcic@ietfa.amsl.com>; Mon, 1 Dec 2014 11:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BFBohX-YdPN7 for <mcic@ietfa.amsl.com>; Mon, 1 Dec 2014 11:12:24 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6E9561A8972 for <mcic@ietf.org>; Mon, 1 Dec 2014 11:11:06 -0800 (PST)
Received: from [] by server-1.bemta-3.messagelabs.com id 1B/8E-18267-94DBC745; Mon, 01 Dec 2014 19:11:05 +0000
X-Env-Sender: Guenter.Klas@vodafone.com
X-Msg-Ref: server-5.tower-169.messagelabs.com!1417461063!9374880!2
X-Originating-IP: []
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 475 invoked from network); 1 Dec 2014 19:11:03 -0000
Received: from mailout10.vodafone.com (HELO mailout10.vodafone.com) ( by server-5.tower-169.messagelabs.com with SMTP; 1 Dec 2014 19:11:03 -0000
Received: from mailint10.vodafone.com (localhost []) by mailout10.vodafone.com (Postfix) with ESMTP id 95D573002E4 for <mcic@ietf.org>; Mon, 1 Dec 2014 20:11:02 +0100 (CET)
Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint10.vodafone.com (Postfix) with ESMTPS id 5035930028F; Mon, 1 Dec 2014 20:11:02 +0100 (CET)
Received: from VOEXC27W.internal.vodafone.com ( by VOEXC02W.internal.vodafone.com ( with Microsoft SMTP Server (TLS) id; Mon, 1 Dec 2014 20:11:01 +0100
Received: from VOEXM01W.internal.vodafone.com ([]) by voexc27w ([]) with mapi id 14.03.0181.006; Mon, 1 Dec 2014 20:11:00 +0100
From: "Klas, Guenter, Vodafone Group" <Guenter.Klas@vodafone.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>, Greg Wilkins <gregw@intalio.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <sbordet@intalio.com>, Larry Masinter <masinter@adobe.com>, Barry Leiba <barryleiba@computer.org>, Pete Resnick <presnick@qualcomm.com>, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, Jari Arkko <jari.arkko@ericsson.com>, "Kathleen.Moriarty.ietf@gmail.com" <Kathleen.Moriarty.ietf@gmail.com>, Alissa Cooper <alissa@cooperw.in>, Richard Barnes <rlb@ipv.sx>, Sean Turner <turners@ieca.com>, "joe@salowey.net" <joe@salowey.net>, "hannes.tschofenig@gmx.net" <hannes.tschofenig@gmx.net>, "fielding@gbiv.com" <fielding@gbiv.com>, "kolkman@isoc.org" <kolkman@isoc.org>, "allison.mankin@gmail.com" <allison.mankin@gmail.com>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>, "J.deBorst@F5.com" <J.deBorst@F5.com>, "Peter Saint-Andre" <stpeter@stpeter.im>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "emile.stephan@orange.com" <emile.stephan@orange.com>, "Brian Raymor (MS OPEN TECH)" <Brian.Raymor@microsoft.com>, "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, Roberto Peon <fenix@google.com>, Martin Nilsson <nilsson@opera.com>, Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>, "dmitry.anipko@microsoft.com" <dmitry.anipko@microsoft.com>, Craig Taylor <craig.taylor@bbc.co.uk>, "Mike Jones" <Michael.Jones@microsoft.com>, Simon Pietro Romano <spromano@unina.it>
Thread-Topic: [Mcic] Summary + Next Steps from Web Obj Security bar BoF - Sunday Nov 9th
Thread-Index: AdANi7zGM4MHLbyrRpqPIqYPF43HIg==
Date: Mon, 1 Dec 2014 19:10:59 +0000
Message-ID: <47D341CC8B26E84FB8A5F7108884CFD47A23356D@VOEXM01W.internal.vodafone.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
Content-Type: multipart/mixed; boundary="_004_47D341CC8B26E84FB8A5F7108884CFD47A23356DVOEXM01Winterna_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mcic/VqU6-ySd1OuVmRFYJj9nyOVizzU
X-Mailman-Approved-At: Mon, 01 Dec 2014 23:09:20 -0800
Cc: "mcic@ietf.org" <mcic@ietf.org>
Subject: [Mcic] Summary + Next Steps from 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\) > " <mcic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcic>, <mailto:mcic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mcic/>
List-Post: <mailto:mcic@ietf.org>
List-Help: <mailto:mcic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcic>, <mailto:mcic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Dec 2014 19:12:35 -0000

Web Object Security bar BoF  at IETF 91 - next steps

Hi there,

You recall, we had the "Multiparty Content Integrity and Confidentiality" bar BoF in Hawaii on Sunday and also talked about web object security.  Thanks to all who participated, prepared some stuff and to Dan Wing for having chaired the session.

Here some takeaways and suggested next steps.

-          Based on the introduction from Dan D. and Julien, we gathered a number of use cases which people found relevant or associated with the problem space. See the use case slide as edited by Dan Wing.

-          Several people felt the number of use cases is too high, better to narrow the list down to a few use cases which can gain good support (e.g. caching, bandwidth consumption, optimisation).

-          Feedback that the problem statement should be articulated more concisely, building on the top few use cases of interest, explaining the non-technical and the related technical issues that require a solution.

-          Maybe a degree of misunderstanding was produced and needs to be corrected, as the objective is certainly NOT to break TLS.

Worth also to say that the intent fits to what Jari mentioned in his IETF 91 blog summary at http://www.ietf.org/blog/2014/11/ietf-91-summary/ : "We need deployable security solutions, we need technology that enables the network to do its work (addressing, caches, ...) while protecting privacy, and we need algorithms that we know we can trust. Hard work ahead!"

Next possible steps:

-          The group to prioritise the use cases as gathered at IETF 91. Can use a Doodle poll as suggested by Dan W.

-          Firming up the problem description. Explaining clearly what non-technical problem exists AND describing the technical problem(s) one level below the use cases.

-          Following up on some of the more detailed questions/aspects already raised at the bar BoF.

-          Involving additional experts who might have an interest in this area.

-          Using the discussion on the mailing list to create material that is sufficient to justify a proper BoF session in the future.


From: Mcic [mailto:mcic-bounces@ietf.org] On Behalf Of Salvatore Loreto
Sent: 04 November 2014 18:55
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
Cc: mcic@ietf.org
Subject: [Mcic] Web Obj Security bar BoF - Sunday Nov 9th


While you are getting ready for your next surfing adventure in the clear waters 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 has been clearly identified and articulated in RFC 7258( https://tools.ietf.org/html/rfc7258 )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 generations' internet users with tools that make unlawful monitoring difficult 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 fend off the new (or old) threats. We live in a digital 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 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 better security in the protocols we develop to preserve and protect the privacy 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 allowing more complex internet delivery methods to be implemented and deployed. From content distribution networks to interconnected web of things we are looking at a very sophisticated mesh where connections are optimized and enhanced by specialized intermediaries that improve efficiency and quality of experience. In fact RFC 7258 acknowledges that certain forms of monitoring 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 internet, the use cases that require multi party negotiation for content integrity 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 importantly 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 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 might 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 understand that some of you might have obligations to be there, we hope that you 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