From nobody Tue Oct 17 05:34:45 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F27F132153 for ; Tue, 17 Oct 2017 05:34:44 -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 autolearn_force=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 cnynvzrrb38f for ; Tue, 17 Oct 2017 05:34:42 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0324213292E for ; Tue, 17 Oct 2017 05:34:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3yGZQ81gxGz15LdK; Tue, 17 Oct 2017 14:34:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc4qb0gvVwon; Tue, 17 Oct 2017 14:34:38 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 17 Oct 2017 14:34:37 +0200 (CEST) To: "maprg@irtf.org" , Dave Plonka From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Tue, 17 Oct 2017 14:34:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Maprg] Agenda and preliminary slot X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Oct 2017 12:34:44 -0000 Hi group, we just uploaded our final agenda for IETF100 in Singapore: https://datatracker.ietf.org/meeting/100/materials/agenda-100-maprg/ Our preliminary agenda slot is scheduled for Monday afternoon 15:50-17:20. The final agenda will be publish this Friday, so please check again later to make sure you have the right time and day! See you all in Singapore! Mirja and Dave From nobody Fri Oct 20 17:25:41 2017 Return-Path: X-Original-To: maprg@irtf.org Delivered-To: maprg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B15C6134499; Fri, 20 Oct 2017 17:24:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Secretariat\"" To: , Cc: maprg@irtf.org, irtf-chair@irtf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854545471.20809.8385590110800129021.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:14 -0700 Archived-At: Subject: [Maprg] maprg - Requested session has been scheduled for IETF 100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 00:24:15 -0000 Dear Mirja Kühlewind, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. maprg Session 1 (1:30:00) Monday, Afternoon Session II 1550-1720 Room Name: Padang size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Measurement and Analysis for Protocols Area Name: IRTF Session Requester: Mirja Kühlewind Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 160 Conflicts to Avoid: First Priority: alto tsvarea mptcp tcpinc ippm iccrg tcpm aqm taps rmcat tsvwg httpbis quic Second Priority: artarea intarea 6man dnsop v6ops uta rtcweb dispatch saag Third Priority: irtfopen lmap avtcore People who must be present: Mirja Kuehlewind Dave Plonka Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Oct 25 05:01:47 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C5A1377B3 for ; Wed, 25 Oct 2017 05:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 Jm9L3QluGEQv for ; Wed, 25 Oct 2017 05:01:37 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA083137C2E for ; Wed, 25 Oct 2017 05:01:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3yMTJJ2lVsz15LtJ for ; Wed, 25 Oct 2017 14:01:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfgCimL-zrQ2 for ; Wed, 25 Oct 2017 14:01:33 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC26AD.dip0.t-ipconnect.de [93.236.38.173]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA for ; Wed, 25 Oct 2017 14:01:33 +0200 (CEST) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary="Apple-Mail=_66DB0FBA-D7FD-46DC-AF76-D552D0A60D9A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <285DACF7-3B51-403F-BB1F-41834B604289@tik.ee.ethz.ch> References: <8777cf4c-499f-71b2-7da6-02f08d208bde@network-heretics.com> To: maprg@irtf.org Date: Wed, 25 Oct 2017 14:01:31 +0200 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Maprg] Fwd: Ben Campbell's Yes on draft-ietf-uta-email-deep-09: (with COMMENT) X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 12:01:45 -0000 --Apple-Mail=_66DB0FBA-D7FD-46DC-AF76-D552D0A60D9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi group, I=E2=80=99m forwarding a snip from the uta mailing list because there is = a request for data. The question is how many of the deployed mail = clients use/support TLS1.2 or higher. Does anybody has data? Mirja > Anfang der weitergeleiteten Nachricht: >=20 > Von: Keith Moore > Betreff: Aw: Ben Campbell's Yes on draft-ietf-uta-email-deep-09: (with = COMMENT) > Datum: 25. Oktober 2017 um 12:48:37 MESZ > An: Ben Campbell , The IESG > Kopie: uta@ietf.org, draft-ietf-uta-email-deep@ietf.org, = uta-chairs@ietf.org, leifj@sunet.se >=20 >> -4.1, last paragraph: "It is RECOMMENDED that new users be required = to use TLS >> version 1.1 >> or greater from the start." >> Is 1.1 correct? Why not start with 1.2? >=20 > TLS 1.1 was a deliberate choice. Reality is that some new users will = still be using old mail user agents, and there are often other factors = that impair users' ability to upgrade. If new users were _required_ to = use TLS 1.2, that would essentially prevent them from getting new email = service, or maybe force them to spend large amounts of money for new = hardware and/or software in order to do so. Either that or mail service = providers might legitimately claim that they had good reason to take = exception to the RECOMMENDED keyword and the paragraph would have no = beneficial effect. >=20 > It's basically a judgment call - what policy on the part of mail = service providers results in the best security overall? It appears = possible to err on the side of either too strict or too loose. >=20 > That said, some of the text in this draft is three years old, and = conditions have changed somewhat in that interval. If 99% of deployed = user agents implement TLS 1.2, requiring 1.2 for new users would = probably not bother me. But if the figure were closer to 90%, it would = bother me. Maybe someone has actual figures, but I suspect the actual = level of deployment is still well less than 90%. --Apple-Mail=_66DB0FBA-D7FD-46DC-AF76-D552D0A60D9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi group,

I=E2=80=99m forwarding a snip from the uta mailing list = because there is a request for data. The question is how many of the = deployed mail clients use/support TLS1.2 or higher. Does anybody has = data?

Mirja


Anfang = der weitergeleiteten Nachricht:

Von: = Keith Moore <moore@network-heretics.com>
Betreff: = Aw: Ben = Campbell's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)
Datum: = 25. Oktober 2017 um 12:48:37 = MESZ
An: = Ben Campbell <ben@nostrum.com>, The = IESG <iesg@ietf.org>
Kopie: = uta@ietf.org, draft-ietf-uta-email-deep@ietf.org, uta-chairs@ietf.org, = leifj@sunet.se

-4.1, last paragraph: "It is = RECOMMENDED that new users be required to use TLS
version = 1.1
   or greater from the start."
Is 1.1 correct? Why not start with 1.2?

TLS 1.1 was a = deliberate choice.  Reality is that some new users will still be = using old mail user agents, and there are often other factors that = impair users' ability to upgrade.   If new users were = _required_ to use TLS 1.2, that would essentially prevent them from = getting new email service, or maybe force them to spend large amounts of = money for new hardware and/or software in order to do so.  Either = that or mail service providers might legitimately claim that they had = good reason to take exception to the RECOMMENDED keyword and the = paragraph would have no beneficial effect.

It's basically a judgment call - what policy on = the part of mail service providers results in the best security = overall?   It appears possible to err on the side of either = too strict or too loose.

That said, some of the text in this draft is = three years old, and conditions have changed somewhat in that = interval.   If 99% of deployed user agents implement TLS 1.2, = requiring 1.2 for new users would probably not bother me.  But if = the figure were closer to 90%, it would bother me.   Maybe = someone has actual figures, but I suspect the actual level of deployment = is still well less than 90%.

= --Apple-Mail=_66DB0FBA-D7FD-46DC-AF76-D552D0A60D9A-- From nobody Mon Oct 30 04:23:58 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03CF13F717 for ; Mon, 30 Oct 2017 04:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 EEGnCga1kg9p for ; Mon, 30 Oct 2017 04:23:50 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 8785713F60A for ; Mon, 30 Oct 2017 04:23:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,319,1505772000"; d="scan'208";a="298516975" Received: from marly.loria.fr (HELO [152.81.8.41]) ([152.81.8.41]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 30 Oct 2017 12:23:48 +0100 From: =?UTF-8?B?SsOpcsO0bWUgRnJhbsOnb2lz?= To: maprg@irtf.org Message-ID: <30e6d3bf-8e10-8e54-392c-54954f543367@inria.fr> Date: Mon, 30 Oct 2017 12:23:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Topics: cfp Subject: [Maprg] IEEE/IFIP Man2Block 2018 - Call for Papers - Submission Deadline: January 5, 2018 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 11:23:53 -0000 ====================================================================== IEEE/IFIP Man2Block 2018 International Workshop on Managing and Managed by Blockchain Colocated with IEEE/IFIP NOMS 2018, 27 April 2018, Taipei, Taiwan https://man2block.inria.fr Paper submission: January 5, 2018 Notification to authors: February 28, 2018 Camera ready: March 16, 2018 Workshop date: April 27, 2018 ====================================================================== The blockchain technologies and their ecosystem are growing at a high pace. Starting from bitcoin, there are now numerous blockchain technologies and applications, with new ones appearing every month. Although all these innovations reside in cryptographic research and developments, blockchain is firstly a distributed system. The underlying infrastructure is blindly leveraged by blockchain technologies whereas this arises serious concerns in terms of scalability, quality-of-service, security and fault tolerance. Indeed, monitoring and configuring such a distributed system without or with a loosely control is naturally difficult. Even fully understanding and predicting expected performance before a real deployment at large scale is vital from a technical and business operations perspective. Furthermore, blockchain is also a potential candidate to ease network and service management. Indeed, many services over Internet rely on pre-establish trust among entities which is hard to maintain at large scale and which are thus the sources of many malfunctioning or the targets of attacks. Among them, we can cite the naming services, the distributed cloud management, resource sharing, the PKI management, or even distributed policy management and accountability within a sofwtarized network architecture. Man2Block 2018 is a dedicated venue for bringing together students, researchers and practitioners from academia and industry who share common interests in the management and the use of the blockchain infrastructure and smart contracts in network, system, service operations and management. Theoretical approaches, practical experimentations and papers highlighting future trends and challenges are welcomed. Authors are invited to submit original contributions (full and short papers) that fall into the following list of topics of interest (not exhaustive): - Blockchain infrastructure management - Security - Monitoring and configuration - Anomaly detection - Resource provisioning - Blockchain QoS and QoE - Large-scale experimentation - Smart contract management - Auditing - Threat assessment - Privacy and anonymity - PKI for blockchains - Simulation and evaluation methodologies - Analytics - Attack design and mitigation - Blockchain architectures ====================================================================== Venue: Man2Block will be held in conjunction with IEEE/IFIP Network Operations and Management Symposium (NOMS) 2018 in Taipei, Taiwan, 27 April 2018 Submission Instructions: Prospective authors are invited to submit original, unpublished works for publication in the IEEE NOMS 2018 proceedings and for presentation in the workshop. Papers under review elsewhere must not be submitted to the workshop. Submissions must be in IEEE 2-column style and have a maximum length of 6 pages (full paper) or 4 pages (short paper). The accepted papers will be submitted for publication in the IEEE Xplore Digital Library. Papers will be withdrawn from IEEE Xplore in case the authors do not present their paper at the workshop Submissions must be made in PDF format via: https://jems.sbc.org.br/home.cgi?c=2939 ====================================================================== Man2Block Workshop co-chairs Jérôme François, Inria Nancy Grand Est, France Abdelkader Lahmadi, Université de Lorraine, France Radu State, University of Luxembourg, Luxembourg Burkhard Stiller, University of Zurich, Switzerland