From nobody Tue Apr 3 02:29:14 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107C812D77A for ; Tue, 3 Apr 2018 02:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matrix.org 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 nqBr35h_NifA for ; Tue, 3 Apr 2018 02:29:10 -0700 (PDT) Received: from hermes.matrix.org (hermes.matrix.org [83.136.254.153]) (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 1052312E856 for ; Tue, 3 Apr 2018 02:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matrix.org; s=hermes; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=co5QCp8LGsZYvMyfNekOqgAweOnXNh2kwyff6sFao9I=; b=UEb+dzLQT8w+G/Bp1u9iZjJKCElbdD7m/um8VibInN0gpfAR82j0NbxiGQTC74UoWqb0soqVX1dc3xKy3l/4Zu1J3Ut56Yggl71q3H0Ztkua7TlxjRHKj6OtQfKaJtTofzSXUaog0sq8ReZNhZXjmQmY3wOnWvo158zz+rQXdPxzAixonqck++bfIxysb8GNgJuLXp5jpMcN2EC54uaOxX4S3FOa6Z5DQCspUHRk4gQXDGAg0B4DhQ9zaQ8Ay2LjuEx5SCEGd1SCTkduRmmLrQgcYE3gSwITQ5O9fOoZpNErDv+BBe0xiZPHUOKmQhI0bXa72VJ2Xbg13Jy8QxHb0w==; Received: from [91.110.5.109] (helo=sierra.local) by hermes.matrix.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1f3IFY-0000sb-9w for mls@ietf.org; Tue, 03 Apr 2018 09:29:08 +0000 To: mls@ietf.org From: Matthew Hodgson Organization: Matrix.org Foundation Message-ID: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> Date: Tue, 3 Apr 2018 10:29:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 09:29:13 -0000 Hi all, [TL;DR: MLS doesn't seem to support decentralisation. Can we fix that, especially given it'll help solve other problems too? I have a handwavey proposal.] Since IETF101 I've been trying to work out how well MLS could be applied in fully decentralised environments which lack any single controlling server, as it seems that the current proposal effectively rules this out due to the state sequencing requirements (thanks to Ben Schwartz for spelling this out to me after the BOF!). This feels like it could be quite a large oversight, given there are many real-time communication protocols and services (e.g. Matrix[1], Tox[2], Briar[3], Secure Scuttlebutt[4], Whisper[5], PSS[6], psyc2[7], XMPP FMUCs[8] (and MIX?), even NNTP and SMTP) where messages are replicated over a network of peers without any single controlling server - all of which could benefit from the well specified, interoperable & scalable group e2e encryption that MLS promises! There's also a more ideological argument that interoperable communication is such a fundamental right that the IETF should support services which support communication without a necessary central logical point of control (much as the internet itself is decentralised). More practically, there may be some benefit to considering decentralisation in MLS in general: for instance, general solutions to races and key synchronisation within a decentralised network could also solve races in a centralised deployment. It could also improve scalability and geo-redundancy by avoiding the need for an atomic ordering system for state changes. To give some concrete context: all conversations in Matrix are expressed as Merkle DAGs of messages which are replicated over the participating servers using eventual consistency semantics (a bit like a full mesh of Git repositories all constantly pushing commits to one another). As a result the conversation DAG often forks: either due to races, partitioned networks, disconnected or offline servers etc - but these temporary forks are very much a desirable feature, allowing partially disconnected operation (e.g. letting a site continue communicating locally even when isolated from the wider network), and aiding scalability (no need for global locks or sequencing). Currently Matrix uses Olm[9] (a Double Ratchet Algorithm implementation) to maintain a full mesh of secure 1:1 channels between devices, and then shares a group ratchet (Megolm[10]) per sender over these channels. The megolm ratchet is a simple hash ratchet which advances every message, and is replaced every N messages (or when group membership changes). The cost of replacement is O(N) with the size of the group, as is the cost of adding users to the group, which obviously makes ART & MLS’s O(log N) behaviour appealing. However, the eventual consistency semantics of a decentralised protocol introduce challenges for E2E encryption: for instance, the membership of a given room is not well defined, as there may be a partition of the room (either due to races or netsplit) which include devices or users that a sender is not yet aware of. This mandates a way of retrospectively syncing message keys between devices after such a fork: deliberately prioritising UX (ensuring messages that users expect to be able to decrypt can be decrypted) over forward secrecy. The same mechanism can be used for cross-device history sync or sharing history from before users join a group. In Matrix we solve this by letting devices share group ratchet key state between each other over Olm by making so-called 'keyshare requests'. Devices must have explicitly verified and trusted the identity of the requesting device before they share keys to it (and currently, keyshare is only supported between a given user's devices - in future we could also support keyshare between all the group's devices if the requester is verified and can provide a proof of permission to view the requested content). This obviously puts a large onus on the device verification mechanism to ensure an attacker isn't able to exfiltrate keys, but our experience has been that the improved UX is worth the risk (plus can always be disabled if needed, e.g. in a single-server centralised deployment). So, how can we support something like this in MLS? There seem to be two main obstacles: 1) the requirement for strict sequencing of state changes, 2) the lack of keyshare semantics to recover from the missing key data which is inevitable in an eventually consistent view of a room. I'm going to ignore the second for now as it can be fixed out of band (although much like attachments, it feels like something which MLS should make /some/ recommendation on, given it can be incredibly useful as a primitive) However, for state sequencing: Am I right in saying that a race between B and C joining a group can cause one client to see a DH binary tree with frontier (AB, C) versus (AC, B), and thus have inconsistent root group keys - messages encrypted during the partition are going to inevitably be undecryptable by the other side? Is there a way where MLS could allow a group to recover from a partition like this by (partially?) rebalancing the DH binary tree into a canonical form once the partition heals? Thus if a partition was detected at the application layer (in Matrix's case, we'd do this by noting that the B-join and C-join events share the same A-join parent), the servers participating in the room would rebalance (AB,C) and (AC,B) to both be (AB,C) and then the conversation could proceed as normal. One might be able to avoid rebalancing the whole tree to minimise CPU impact (although in practice healing these races are fairly rare edge cases). Obviously this assumes that one has a way to request keys to recover the messages lost when the groups were out of sync. If this mechanism makes sense, it seems that it could provide a way to eliminate the "Sequencing of State Changes" requirement entirely from MLS - or at least provide an alternative for folks where either server-side or client-side strict sequencing isn't an option, and so solve the general 'how to handle races' problem mentioned at the BOF (whilst also necessitating an interoperable solution to history/key sharing, similar to the earlier “Use cases for avoiding forward secrecy” thread[11]) Anyway, apologies for the stream of consciousness - feedback from those who properly understand ART & MLS would be hugely appreciated :) thanks, Matthew [1] https://matrix.org/docs/spec [2] https://toktok.ltd/spec.html#introduction [3] https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BTP.md [4] https://ssbc.github.io/scuttlebutt-protocol-guide/ [5] https://github.com/ethereum/go-ethereum/wiki/Whisper [6] https://gist.github.com/zelig/d52dab6a4509125f842bbd0dce1e9440 [7] https://gnunet.org/sites/default/files/gnunet-psyc.pdf [8] https://xmpp.org/extensions/xep-0289.html [9] https://git.matrix.org/git/olm/about/docs/olm.rst [10] https://git.matrix.org/git/olm/about/docs/megolm.rst [11] https://mailarchive.ietf.org/arch/msg/mls/b5YoQfdeFcoLYrFdxbZmdX__jWA P.S. This has probably already been fixed, but the [signal] footnote on https://tools.ietf.org/html/draft-barnes-mls-protocol-00 is credited to "T. and M. Marlinspike" - I think you are missing a 'Perrin'? -- Matthew Hodgson Matrix.org From nobody Tue Apr 3 02:51:44 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7D412E877 for ; Tue, 3 Apr 2018 02:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 f7bP_rSsJJH3 for ; Tue, 3 Apr 2018 02:51:38 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 B2CEE12E876 for ; Tue, 3 Apr 2018 02:51:37 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id p9so32057221wmc.3 for ; Tue, 03 Apr 2018 02:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0S7y6zZ+yE++Icfa1v0CCmBIqyeArSb7owYyUjhdAxc=; b=R9dorMStjYmmDCEHPWIpvCZ761xkXnNRtzTyhPYGS1Goq9diay1pup2tfT8j9pdKNt IMBA+iknjmvwJuEUwmc/+TbiNZ1iUjYLFIT53hquoeYU+eAWz7vp0qjCzWzd56Xs8M6Z R0VNv0BknUW/g1Me7nAEIruXfHblXlhAjWgwY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0S7y6zZ+yE++Icfa1v0CCmBIqyeArSb7owYyUjhdAxc=; b=q7DtdWunCxR2M6VDCshvn00Ivjwhs3wt6qQJZySrcOQvHEjPJeJ2xgC1LKyDA2PJQ3 Nrrbhs/RWe6CMnd+CjUPt32yvHCCt8irLGb5cvr4gfQMXgYAzSkKzaQ0nTFLM/zylSQK 8i3KPdBqZVeC3Xo+UCnjdzQEtwNiGlv3Mr1FJtDKbL8Cp/UMGjguXZwfcqAjCs0AQfef J9kNTVLzycSlAuj6npBTIUj3ytZ+Dbz/J7j1ipHo2Y0HgzC6WVauWe0KV+cq3yuquMYL ckF0qZHjXJ9VqChzH1k1W+MvbXocuIYrMW2rczgXH2DRM2Ac6zFyS08Ej4IbZCGH9GyH hyXA== X-Gm-Message-State: ALQs6tAz09QVtt3uRJExcy7/wwoGYaHJKbgS9ne+5mfHh80iIe6jrV9O mGSs/va0X6OfNFzaiMPq6rnMzG3jpwZvkS0+NNAn2a0Q X-Google-Smtp-Source: AIpwx4/DAEmw8H+7lhQtZJUD1VvDJJ5rdTyblXWmD9T07WSz5AqwONS3vXJG+5KcP6HwfUy6+oBM5TgXUGrHmEGLk6M= X-Received: by 10.46.46.10 with SMTP id u10mr7823563lju.77.1522749096159; Tue, 03 Apr 2018 02:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.71.226 with HTTP; Tue, 3 Apr 2018 02:51:35 -0700 (PDT) In-Reply-To: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> From: Dave Cridland Date: Tue, 3 Apr 2018 10:51:35 +0100 Message-ID: To: Matthew Hodgson Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="089e0823f834f580250568eea603" Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 09:51:41 -0000 --089e0823f834f580250568eea603 Content-Type: text/plain; charset="UTF-8" On 3 April 2018 at 10:29, Matthew Hodgson wrote: > This feels like it could be quite a large oversight, given there are many > real-time communication protocols and services (e.g. Matrix[1], Tox[2], > Briar[3], Secure Scuttlebutt[4], Whisper[5], PSS[6], psyc2[7], XMPP > FMUCs[8] (and MIX?), even NNTP and SMTP) where messages are replicated over > a network of peers without any single controlling server Just as a side-note, the only environment I know of using XMPP FMUC also bans use of end-to-end encryption. MIX (XEP-0369) uses the same model of a single definitive sequence of messages, currently. Neither MUC nor MIX require a single server, however - just a single domain. FMUC differs in simply having multiple "correct" sequences, where the various sequence domains are split by having very lo links in between. This is a trade-off in terms of UX, however - having a single sequence of messages known to all participants (not just their clients) is useful, and of absolutely critical importance in some environments. Dave. --089e0823f834f580250568eea603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 3 April 2018 at 10:29, Matthew Hodgson <matthew@matrix.org>= wrote:
This feels like it could b= e quite a large oversight, given there are many real-time communication pro= tocols and services (e.g. Matrix[1], Tox[2], Briar[3], Secure Scuttlebutt[4= ], Whisper[5], PSS[6], psyc2[7], XMPP FMUCs[8] (and MIX?), even NNTP and SM= TP) where messages are replicated over a network of peers without any singl= e controlling server

Just as a side-note, t= he only environment I know of using XMPP FMUC also bans use of end-to-end e= ncryption. MIX (XEP-0369) uses the same model of a single definitive sequen= ce of messages, currently. Neither MUC nor MIX require a single server, how= ever - just a single domain.

FMUC differs in simpl= y having multiple "correct" sequences, where the various sequence= domains are split by having very lo links in between. This is a trade-off = in terms of UX, however - having a single sequence of messages known to all= participants (not just their clients) is useful, and of absolutely critica= l importance in some environments.

Dave.
--089e0823f834f580250568eea603-- From nobody Tue Apr 3 03:41:59 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0064A12DA07 for ; Tue, 3 Apr 2018 03:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=WaJBRn95; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g7ltO+r/ 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 pDDEpyCXpzNc for ; Tue, 3 Apr 2018 03:41:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087E1127337 for ; Tue, 3 Apr 2018 03:41:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1A47A20AF3 for ; Tue, 3 Apr 2018 06:41:52 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Tue, 03 Apr 2018 06:41:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=Tn/jt2X1MjVd3BSkmVktE1iYzK B4d5t9SoX6nUhf0oM=; b=WaJBRn958Xrbqm1EgNy6WC4TfwFUVoytsEuPe32yRf IOpeOgL+93OP5+EDsYN09WBlnpvH+yXMb0oZAGFRH6G2kDDKkezh8pr4611QyPkU j+VnRFy8UzqiLeK5h7g1Sl3f0Rgkiw6pWsHcyG9uJXynmX4iuCNcfQs+Molp5npc w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Tn/jt2 X1MjVd3BSkmVktE1iYzKB4d5t9SoX6nUhf0oM=; b=g7ltO+r/uJhwu0/vj/tkTl s7nE/BdqTtmNUjZtr2WUoHdr3JTfVh4K150YBsYisEnFDckZb2r830KL+uJZrivJ f4r4Nsjd1E6l8HQCKqR39W41km2diLOSQmflsYGJDHJbnqS8F8sQ11++MF2VnuV4 T7LBIZJCoiv9t6IRQHYAZcr9xWWgL35M8E0r6d86BYwZBuDnCNLpXhQMUWky4wN2 N6Gqav0J4mX/gEoM8uUFhEkyNnJV1QfsyWaC8cQPCU90iSIpZXVZq+cZViHZF5UC MACEYUIRq0tiOIb5mhcVPB5aRFUGK9pPXgrLJGVyYuY0gHU2LONgipLHEQDj+XOA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E52159E0AF; Tue, 3 Apr 2018 06:41:51 -0400 (EDT) Message-Id: <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1522752111783620" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 In-Reply-To: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> Date: Tue, 03 Apr 2018 11:41:51 +0100 Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 10:41:56 -0000 This is a multi-part message in MIME format. --_----------=_1522752111783620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Matthew, Thanks for thinking about this. I agree that it's a problem I think exists even in the centralised world, since it's much nicer to build a system that doesn't have to provide strict sequencing guarantees. # The problem I'll sketch out the underlying problem first, even though I think you spotted it pretty well, just to make sure we're on the same page. The problem is from the ratcheting tree construction: two updates which both want to change a particular intermediate node cannot both be applied at the same time. Let me try out some ASCII art: consider a simple tree like root =E2=94=9C=E2=94=80=E2=94=80 x =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 a =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b =E2=94=94=E2=94=80=E2=94=80 y =E2=94=9C=E2=94=80=E2=94=80 c =E2=94=94=E2=94=80=E2=94=80 d and suppose c wants to update to c', giving the following tree and publishing g^i(y') where y'=3Dg^c'd root =E2=94=9C=E2=94=80=E2=94=80 x =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 a =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b =E2=94=94=E2=94=80=E2=94=80 y' =E2=94=9C=E2=94=80=E2=94=80 c' =E2=94=94=E2=94=80=E2=94=80 d while d also wants to update to d', giving the following tree and publishing g^i(y'') where y''=3Dg^cd' root =E2=94=9C=E2=94=80=E2=94=80 x =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 a =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b =E2=94=94=E2=94=80=E2=94=80 y'' =E2=94=9C=E2=94=80=E2=94=80 c =E2=94=94=E2=94=80=E2=94=80 d' These can't both be applied by A: A can either set their view of the last node on their copath to be y' or y'', but not both of them. Moreover, A has no way of "combining" the two updates. # Not the problem One thing I should highlight up front is that this does not necessarily prevent decrypting messages, only applying key updates. Specifically, if A receives either C's or D's update they can apply it and compute the resulting root key, then decrypt the message. Of course, if the update is one that should have bounced, then they might have to "un-apply" it. Moreover, if A wants to send their own update, they need to pick one of y' and y'' to base it on. This is something I don't think we've reasoned about in detail yet. For other reasons due to malicious group members, I think we're likely to come up with a system where each participant has various "proposed" updates sitting around, and then only confirms them after receiving some other message. This sort of algorithm should also help here, because I think it will also need the ability to unwind or not apply a potential update. # Things we tried that don't yet work One thing we thought about was using some tricks with Diffie-Hellman to allow both updates to be processed at the same time. Unfortunately we couldn't actually come up with a system that works (using a KDF to turn group elements back into integers hurts here), but there might well be one. Another thing is the observation that in fact it is sometimes possible to apply two updates at once: specifically, if two updates change different copath elements with respect to a recipient, then that recipient can apply both of them. Unfortunately this only helps some recipients, not all of them, so it doesn't really solve the whole problem. Another thing is having the server do some clever re-ordering. The challenge is that in the end, by construction the correct value of the intermediate node should only be computable by its children, so there's only so much the server can do. For the same reason, I'm not sure the server can unilaterally rebalance the tree; I think it would need some help from one of the participants. I'd have to think more carefully about the precise keys which it would need to do so, though. In particular, if you are more worried about re- ordering join events than re-ordering key updates, there might be some specialised tricks that work. # Question about the Matrix context In the Matrix setup, do nodes actually know when there is consensus on a particular set of messages? That is, is there some point at which they can conclude "ok, I know that the following messages are actually the right ones, and haven't been pre-empted or undone by successors"? (If so then I think the "multiple proposed updates" ideas will help here too.) does that make sense? :) best, K --_----------=_1522752111783620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Matthew,

Thanks for thinking about this. = I agree that it's a problem I think exists even in the centralised world, s= ince it's much nicer to build a system that doesn't have to provide strict = sequencing guarantees.

# The problem

I'll sketch out the underlying p= roblem first, even though I think you spotted it pretty well, just to make = sure we're on the same page. The problem is from the ratcheting tree constr= uction: two updates which both want to change a particular intermediate nod= e cannot both be applied at the same time. Let me try out some ASCII art: c= onsider a simple tree like

root
=E2=94=9C=E2=94=80=E2=94= =80 x
=E2=94=82   =E2= =94=9C=E2=94=80=E2=94=80 a
=E2=94=82   =E2= =94=94=E2=94=80=E2=94=80 b
=E2=94=94=E2=94=80=E2=94= =80 y
    =E2=94= =9C=E2=94=80=E2=94=80 c
    =E2=94= =94=E2=94=80=E2=94=80 d

and suppose c wants to update to= c', giving the following tree and publishing g^i(y') where y'=3Dg^c'd
<= /div>

root
=E2=94=9C=E2=94=80=E2=94= =80 x
=E2=94=82   =E2= =94=9C=E2=94=80=E2=94=80 a
=E2=94=82   =E2= =94=94=E2=94=80=E2=94=80 b
=E2=94=94=E2=94=80=E2=94= =80 y'
    =E2=94= =9C=E2=94=80=E2=94=80 c'
    =E2=94= =94=E2=94=80=E2=94=80 d

while d also wants to update to = d', giving the following tree and publishing g^i(y'') where y''=3Dg^cd'
=

root=
=E2=94=9C=E2=94=80=E2=94= =80 x
=E2=94=82   =E2= =94=9C=E2=94=80=E2=94=80 a
=E2=94=82   =E2= =94=94=E2=94=80=E2=94=80 b
=E2=94=94=E2=94=80=E2=94= =80 y''
    =E2=94= =9C=E2=94=80=E2=94=80 c
    =E2=94= =94=E2=94=80=E2=94=80 d'

These can't both be applied by A= : A can either set their view of the last node on their copath to be y' or = y'', but not both of them. Moreover, A has no way of "combining" the two up= dates.

# Not the problem

One thing I should highlight up = front is that this does not necessarily prevent decrypting messages, only a= pplying key updates. Specifically, if A receives either C's or D's update t= hey can apply it and compute the resulting root key, then decrypt the messa= ge. Of course, if the update is one that should have bounced, then they mig= ht have to "un-apply" it. Moreover, if A wants to send their own update, th= ey need to pick one of y' and y'' to base it on. This is something I don't = think we've reasoned about in detail yet.

For other reasons due to malicio= us group members, I think we're likely to come up with a system where each = participant has various "proposed" updates sitting around, and then only co= nfirms them after receiving some other message. This sort of algorithm shou= ld also help here, because I think it will also need the ability to unwind = or not apply a potential update.

# Things we tried that don't yet= work

One thing we thought about was u= sing some tricks with Diffie-Hellman to allow both updates to be processed = at the same time. Unfortunately we couldn't actually come up with a system = that works (using a KDF to turn group elements back into integers hurts he= re), but there might well be one.

Another thing is the observation= that in fact it is sometimes possible to apply two updates at once: specif= ically, if two updates change different copath elements with respect to a r= ecipient, then that recipient can apply both of them. Unfortunately this on= ly helps some recipients, not all of them, so it doesn't really solve the w= hole problem.

Another thing is having the serv= er do some clever re-ordering. The challenge is that in the end, by constr= uction the correct value of the intermediate node should only be computable= by its children, so there's only so much the server can do.

For the same reason, I'm not sur= e the server can unilaterally rebalance the tree; I think it would need som= e help from one of the participants. I'd have to think more carefully about= the precise keys which it would need to do so, though. In particular, if y= ou are more worried about re-ordering join events than re-ordering key upda= tes, there might be some specialised tricks that work.

# Question about the Matrix cont= ext

In the Matrix setup, do nodes ac= tually know when there is consensus on a particular set of messages? That i= s, is there some point at which they can conclude "ok, I know that the foll= owing messages are actually the right ones, and haven't been pre-empted or = undone by successors"? (If so then I think the "multiple proposed updates" = ideas will help here too.)




does that make sense? :)

best,
K
--_----------=_1522752111783620-- From nobody Tue Apr 3 14:59:49 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF7112D882 for ; Tue, 3 Apr 2018 14:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matrix.org 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 l7H-K-LkAoG4 for ; Tue, 3 Apr 2018 14:59:44 -0700 (PDT) Received: from hermes.matrix.org (hermes.matrix.org [83.136.254.153]) (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 DCFEA126C2F for ; Tue, 3 Apr 2018 14:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matrix.org; s=hermes; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=EzMwxITTfK2qKZRwWTQabHraOhH+FdOKT78PL4QTjDg=; b=ul8FRGD9UiSQ80oorf7n9aDCnE4jyxGJTdPuP9x1/n//bSZKOyBsGpHLNRAVVUnKLg/7YpgGFx/Vdr3O6rfPVyIuVYnCQ70INLiyQUgAkuRl/SRJMK29dNgBw0nZXzbsSbLoZt1Ik5p16INN48u/w+cU9lw8Ay2ZZahNGEY3BG7ucAE0CHBE47GR/4VFecdlUvPYJVfoe7bjA8pHeqUxzY8npgzK5ZOXGEJf+pd/6yJDMDFpWttQd97Qp8VNim930RIxKrFGhjhkRYWp8HlWcDJBGzLQ0mbHWuSSJfGwxe2PrQpexi1Q+h1cbV5Iq4RCzJrXtC4upXSB+d2QcIUsag==; Received: from [91.110.5.109] (helo=sierra.local) by hermes.matrix.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1f3Txu-0001fM-8S for mls@ietf.org; Tue, 03 Apr 2018 21:59:42 +0000 To: mls@ietf.org References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> From: Matthew Hodgson Organization: Matrix.org Foundation Message-ID: <744b2740-e7fc-0d58-a6c2-1625ef84bb70@matrix.org> Date: Tue, 3 Apr 2018 22:59:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------C8E145A2A6778115BD509AA1" Content-Language: en-GB Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:59:47 -0000 This is a multi-part message in MIME format. --------------C8E145A2A6778115BD509AA1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 03/04/2018 11:41, Katriel Cohn-Gordon wrote: > # The problem > > I'll sketch out the underlying problem first, even though I think you > spotted it pretty well, just to make sure we're on the same page. The > problem is from the ratcheting tree construction: two updates which > both want to change a particular intermediate node cannot both be > applied at the same time. Thanks for the speedy & comprehensive answer (and sorry for being slow at grokking this in person at IETF!) Yup, I think we're on the same page - the only difference is that I've been fixating on races between adding devices to the group (as that's the one which has historically bitten us badly on Matrix) versus races betwen key updates, which is I guess is the more common failure mode for MLS. > # Not the problem > > One thing I should highlight up front is that this does not > necessarily prevent decrypting messages, only applying key updates. > Specifically, if A receives either C's or D's update they can apply it > and compute the resulting root key, then decrypt the message. Of > course, if the update is one that should have bounced, then they might > have to "un-apply" it. Aaaah, interesting. Does this mean that a 'many worlds' style approach can work here, where each client calculates the possible trees resulting in the state changes arriving in different orders, and tries to decrypt the messages using the tree which 'works' (thus avoiding the need for keysharing)? > Moreover, if A wants to send their own update, they need to pick one > of y' and y'' to base it on. This is something I don't think we've > reasoned about in detail yet. > > For other reasons due to malicious group members, I think we're likely > to come up with a system where each participant has various "proposed" > updates sitting around, and then only confirms them after receiving > some other message. This sort of algorithm should also help here, > because I think it will also need the ability to unwind or not apply a > potential update. Okay. Is this the same as the proposed v. committed update strategy mentioned at https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-9.2? > > # Things we tried that don't yet work > > One thing we thought about was using some tricks with Diffie-Hellman > to allow both updates to be processed at the same time. Unfortunately > we couldn't actually come up with a system that works (using a KDF to > turn group elements back into integers hurts here), but there might > well be one. > > Another thing is the observation that in fact it is sometimes possible > to apply two updates at once: specifically, if two updates change > different copath elements with respect to a recipient, then that > recipient can apply both of them. Unfortunately this only helps some > recipients, not all of them, so it doesn't really solve the whole problem. > > Another thing is having the server do some clever re-ordering. The > challenge is that in the end, by construction the correct value of the > intermediate node should only be computable by its children, so > there's only so much the server can do. > > For the same reason, I'm not sure the server can unilaterally > rebalance the tree; I think it would need some help from one of the > participants. I'd have to think more carefully about the precise keys > which it would need to do so, though. In particular, if you are more > worried about re-ordering join events than re-ordering key updates, > there might be some specialised tricks that work. I wasn't thinking of the server rebalancing the tree, but instead there being some kind of mechanism that alerts clients to the fact that there is been a race (e.g. two messages arriving with the same logical timestamp), causing them to all go and rebalance their trees to ensure everyone is back on the same page (to the best of their knowledge) rather than trying to apply the update to the 'wrong' base.  It feels like i'm missing something about the practicality of doing this in terms of the actual DH exchanges though? In a 'many world' model, I guess this would just mean selecting the correct tree from the possibilities being maintained, rather than having to rebalance the currently 'wrong' tree to make it 'correct', which seems a bit cleaner. > # Question about the Matrix context > > In the Matrix setup, do nodes actually know when there is consensus on > a particular set of messages? They do not. We don't currently have a consensus mechanism which seals the history - instead, it's perfectly valid for a netsplit to cause a room to go off on a long-lived evolutionary fork. We have considered sealing history in the context of transcript consistency however, as having a canonical version of the room can obviously be useful to avoid situations where folks insert or reject messages in their local fork of the room in order to twist the conversation.  It could also be useful when changing the replication algorithm (atomically sealing the history of the room on the old protocol before switching over to the new). However, we'd prefer to avoid forcing participants into committing to a 'one true copy of the room' as it effectively introduces centralisation, as well breaking the whole long-lived fork use cases.  Instead it'd probably be nicer to commit to transcript consistency *for a given partition of the room*, which we effectively already have via the Merkle signing of the Matrix room DAG. > That is, is there some point at which they can conclude "ok, I know > that the following messages are actually the right ones, and haven't > been pre-empted or undone by successors"? (If so then I think the > "multiple proposed updates" ideas will help here too.) So I wonder if the "many worlds" or "multiple proposed updates" idea works even if your forks can be longlived - it's just that the proposals can drag on for a long time and are never necessarily fully committed to.  Is this actually a problem?  I think I'm missing the attacks which you are considering... > does that make sense? :) mostly, I think! M -- Matthew Hodgson Matrix.org --------------C8E145A2A6778115BD509AA1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 03/04/2018 11:41, Katriel Cohn-Gordon wrote:
# The problem

I'll sketch out the underlying problem first, even though I think you spotted it pretty well, just to make sure we're on the same page. The problem is from the ratcheting tree construction: two updates which both want to change a particular intermediate node cannot both be applied at the same time.

Thanks for the speedy & comprehensive answer (and sorry for being slow at grokking this in person at IETF!)

Yup, I think we're on the same page - the only difference is that I've been fixating on races between adding devices to the group (as that's the one which has historically bitten us badly on Matrix) versus races betwen key updates, which is I guess is the more common failure mode for MLS.

# Not the problem

One thing I should highlight up front is that this does not necessarily prevent decrypting messages, only applying key updates. Specifically, if A receives either C's or D's update they can apply it and compute the resulting root key, then decrypt the message. Of course, if the update is one that should have bounced, then they might have to "un-apply" it.

Aaaah, interesting. Does this mean that a 'many worlds' style approach can work here, where each client calculates the possible trees resulting in the state changes arriving in different orders, and tries to decrypt the messages using the tree which 'works' (thus avoiding the need for keysharing)?

Moreover, if A wants to send their own update, they need to pick one of y' and y'' to base it on. This is something I don't think we've reasoned about in detail yet.

For other reasons due to malicious group members, I think we're likely to come up with a system where each participant has various "proposed" updates sitting around, and then only confirms them after receiving some other message. This sort of algorithm should also help here, because I think it will also need the ability to unwind or not apply a potential update.

Okay. Is this the same as the proposed v. committed update strategy mentioned at https://tools.ietf.org/html/draft-barnes-mls-protocol-00#section-9.2?


# Things we tried that don't yet work

One thing we thought about was using some tricks with Diffie-Hellman to allow both updates to be processed at the same time. Unfortunately we couldn't actually come up with a system that works (using a KDF to turn group elements back into integers hurts here), but there might well be one.

Another thing is the observation that in fact it is sometimes possible to apply two updates at once: specifically, if two updates change different copath elements with respect to a recipient, then that recipient can apply both of them. Unfortunately this only helps some recipients, not all of them, so it doesn't really solve the whole problem.

Another thing is having the server do some clever re-ordering. The challenge is that in the end, by construction the correct value of the intermediate node should only be computable by its children, so there's only so much the server can do.

For the same reason, I'm not sure the server can unilaterally rebalance the tree; I think it would need some help from one of the participants. I'd have to think more carefully about the precise keys which it would need to do so, though. In particular, if you are more worried about re-ordering join events than re-ordering key updates, there might be some specialised tricks that work.

I wasn't thinking of the server rebalancing the tree, but instead there being some kind of mechanism that alerts clients to the fact that there is been a race (e.g. two messages arriving with the same logical timestamp), causing them to all go and rebalance their trees to ensure everyone is back on the same page (to the best of their knowledge) rather than trying to apply the update to the 'wrong' base.  It feels like i'm missing something about the practicality of doing this in terms of the actual DH exchanges though?

In a 'many world' model, I guess this would just mean selecting the correct tree from the possibilities being maintained, rather than having to rebalance the currently 'wrong' tree to make it 'correct', which seems a bit cleaner.

# Question about the Matrix context

In the Matrix setup, do nodes actually know when there is consensus on a particular set of messages?

They do not. We don't currently have a consensus mechanism which seals the history - instead, it's perfectly valid for a netsplit to cause a room to go off on a long-lived evolutionary fork.

We have considered sealing history in the context of transcript consistency however, as having a canonical version of the room can obviously be useful to avoid situations where folks insert or reject messages in their local fork of the room in order to twist the conversation.  It could also be useful when changing the replication algorithm (atomically sealing the history of the room on the old protocol before switching over to the new).

However, we'd prefer to avoid forcing participants into committing to a 'one true copy of the room' as it effectively introduces centralisation, as well breaking the whole long-lived fork use cases.  Instead it'd probably be nicer to commit to transcript consistency *for a given partition of the room*, which we effectively already have via the Merkle signing of the Matrix room DAG.

That is, is there some point at which they can conclude "ok, I know that the following messages are actually the right ones, and haven't been pre-empted or undone by successors"? (If so then I think the "multiple proposed updates" ideas will help here too.)

So I wonder if the "many worlds" or "multiple proposed updates" idea works even if your forks can be longlived - it's just that the proposals can drag on for a long time and are never necessarily fully committed to.  Is this actually a problem?  I think I'm missing the attacks which you are considering...

does that make sense? :)

mostly, I think!

M


-- 
Matthew Hodgson
Matrix.org
--------------C8E145A2A6778115BD509AA1-- From nobody Tue Apr 3 19:23:25 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32F0127863 for ; Tue, 3 Apr 2018 19:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EpI5ugxks36V for ; Tue, 3 Apr 2018 19:23:21 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 60EE91243FE for ; Tue, 3 Apr 2018 19:23:21 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id n40-v6so21679617otd.3 for ; Tue, 03 Apr 2018 19:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0UeSKb8laz92kyHpuIqy5QJMjtVNrccndCu8lW8ghZ0=; b=ma8RVT7qjIDCxSrPxtZTsTZvf/nglJsSUuyTMNl2up7krxAqYvnshPo64EHNI1+Ro+ y27A1h2sCVrYKr8YL4ZfuzbgA24cFdKWUb0s2+118YY4jNThdSPhZF8DKsGrqevf2F5x ND7hrEk5Km8k4HLIK0sO4zHsG9emtKQ5tCnUqjzaxKLajYLp+Gq+0vBGO58v4J/8cyjE EkTZUjcT0o/cfu+sF8VDG6yNOoHnRv8jhGe7o+CurtDn/78igsz30sCLe3cb7RD2ffUk SRHyYUZwghYmG1SEEwFwFQtv0LzeHCeD8dDz6sA+E2xBikH+aUI/FIaUGv0BXNzqoqvF 7Trw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0UeSKb8laz92kyHpuIqy5QJMjtVNrccndCu8lW8ghZ0=; b=XbWgjaEdRVhlopLR1KzNB157tR5oZT5NoJ+LGdrxQgNlOQ5qL2kfxCroCr2J22Pinl FKRnf6zkFDAt5I5vTkOq0sTVPNIj9tArDcaHftjy/e7JTcP0FUyFSVo9n3TPK1U1HpFl 3Pi8wZp6nbrdWUTqn/RehSzaEoJr5wKeaKeLl/W5Ig9CMike9hP/Nnpp/HIotUrH9Le2 s5IT4WUfpdO9UC9bYfaxwznQL7mLADbhLDePBJhrj0QZbkBlTKLxM0fuhE1EawqlyelN XcU04vdfqtjVotZddmYOBdcVUcofzXGthUR7ALXZApZDgg7kD26Bc9KqqhvIBZmH948q xo0w== X-Gm-Message-State: ALQs6tC4Gr0ITpyzJjGOPGRLJuzqHdCFJTrOwD7O3qefFWPkYFWU8AGL qnVRJRmFpU1UJVGzdl9HGCyGB/ar52lxj0ppT+Gk8Q== X-Google-Smtp-Source: AIpwx4/Fo86+eu/6NXp4GbmAjSxBCfGViooKoDEVDETj5K8hpGafGqk3yCQGgup9fjp4dJvBSi//W4GIRWjkqt8KE40= X-Received: by 2002:a9d:4541:: with SMTP id p1-v6mr10068938oti.15.1522808600433; Tue, 03 Apr 2018 19:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:ac7:0:0:0:0:0 with HTTP; Tue, 3 Apr 2018 19:23:19 -0700 (PDT) In-Reply-To: <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> From: Martin Thomson Date: Wed, 4 Apr 2018 12:23:19 +1000 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 02:23:24 -0000 Is it possible to have a common tie-breaker process and force the loser to rebase? That is, if the change c->c' wins, then d needs to apply their d->d' change again on top of that change (or move to d''). A simple tie breaker process would inform all participants of the head of both forks and to pick a winner based on the one that gets the largest result from H(root). That's open to participants choosing keys to influence the result, so you probably don't want that precise design (esp. if forks include removals), but hopefully the idea makes sense. The next problem would be that repair of a fork can be expensive. If there are multiple changes on the losing fork, then all those changes might also compete as the updates propagate. On Tue, Apr 3, 2018 at 8:41 PM, Katriel Cohn-Gordon wrot= e: > Hi Matthew, > > Thanks for thinking about this. I agree that it's a problem I think exist= s > even in the centralised world, since it's much nicer to build a system th= at > doesn't have to provide strict sequencing guarantees. > > # The problem > > I'll sketch out the underlying problem first, even though I think you > spotted it pretty well, just to make sure we're on the same page. The > problem is from the ratcheting tree construction: two updates which both > want to change a particular intermediate node cannot both be applied at t= he > same time. Let me try out some ASCII art: consider a simple tree like > > root > =E2=94=9C=E2=94=80=E2=94=80 x > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 a > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b > =E2=94=94=E2=94=80=E2=94=80 y > =E2=94=9C=E2=94=80=E2=94=80 c > =E2=94=94=E2=94=80=E2=94=80 d > > and suppose c wants to update to c', giving the following tree and > publishing g^i(y') where y'=3Dg^c'd > > root > =E2=94=9C=E2=94=80=E2=94=80 x > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 a > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b > =E2=94=94=E2=94=80=E2=94=80 y' > =E2=94=9C=E2=94=80=E2=94=80 c' > =E2=94=94=E2=94=80=E2=94=80 d > > while d also wants to update to d', giving the following tree and publish= ing > g^i(y'') where y''=3Dg^cd' > > root > =E2=94=9C=E2=94=80=E2=94=80 x > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 a > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 b > =E2=94=94=E2=94=80=E2=94=80 y'' > =E2=94=9C=E2=94=80=E2=94=80 c > =E2=94=94=E2=94=80=E2=94=80 d' > > These can't both be applied by A: A can either set their view of the last > node on their copath to be y' or y'', but not both of them. Moreover, A h= as > no way of "combining" the two updates. > > # Not the problem > > One thing I should highlight up front is that this does not necessarily > prevent decrypting messages, only applying key updates. Specifically, if = A > receives either C's or D's update they can apply it and compute the > resulting root key, then decrypt the message. Of course, if the update is > one that should have bounced, then they might have to "un-apply" it. > Moreover, if A wants to send their own update, they need to pick one of y= ' > and y'' to base it on. This is something I don't think we've reasoned abo= ut > in detail yet. > > For other reasons due to malicious group members, I think we're likely to > come up with a system where each participant has various "proposed" updat= es > sitting around, and then only confirms them after receiving some other > message. This sort of algorithm should also help here, because I think it > will also need the ability to unwind or not apply a potential update. > > # Things we tried that don't yet work > > One thing we thought about was using some tricks with Diffie-Hellman to > allow both updates to be processed at the same time. Unfortunately we > couldn't actually come up with a system that works (using a KDF to turn > group elements back into integers hurts here), but there might well be on= e. > > Another thing is the observation that in fact it is sometimes possible to > apply two updates at once: specifically, if two updates change different > copath elements with respect to a recipient, then that recipient can appl= y > both of them. Unfortunately this only helps some recipients, not all of > them, so it doesn't really solve the whole problem. > > Another thing is having the server do some clever re-ordering. The challe= nge > is that in the end, by construction the correct value of the intermediate > node should only be computable by its children, so there's only so much t= he > server can do. > > For the same reason, I'm not sure the server can unilaterally rebalance t= he > tree; I think it would need some help from one of the participants. I'd h= ave > to think more carefully about the precise keys which it would need to do = so, > though. In particular, if you are more worried about re-ordering join eve= nts > than re-ordering key updates, there might be some specialised tricks that > work. > > # Question about the Matrix context > > In the Matrix setup, do nodes actually know when there is consensus on a > particular set of messages? That is, is there some point at which they ca= n > conclude "ok, I know that the following messages are actually the right > ones, and haven't been pre-empted or undone by successors"? (If so then I > think the "multiple proposed updates" ideas will help here too.) > > > > > does that make sense? :) > > best, > K > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > From nobody Wed Apr 4 03:16:16 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FBE126DEE for ; Wed, 4 Apr 2018 03:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=d+UuJvwL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AxBhX3FK 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 b98UOffW4Im6 for ; Wed, 4 Apr 2018 03:16:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8F4124E15 for ; Wed, 4 Apr 2018 03:16:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A3BBD20EE2 for ; Wed, 4 Apr 2018 06:16:12 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Wed, 04 Apr 2018 06:16:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=RuYw8KLXl7Xo9XXEvMR+8vx+oZ EDwoEZ40g9akxDN3o=; b=d+UuJvwLFx8Mutn4T7AucTMYJ8lw3Q6nwESH+1PWi5 B/P0vDCefAK2n8ji4B+IVIc2h5/XVUVQAt+dyxJplSECFHboC85kDIKt8HC/iluF YOkqGhwwH0sNyhxyRk1p8tyKJIffWWr64weKqpAQX882hEJLnfj1QOPIMFzDA+iq E= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RuYw8K LXl7Xo9XXEvMR+8vx+oZEDwoEZ40g9akxDN3o=; b=AxBhX3FKKUwER87zo1Zyv1 Ow5/5Qr+U0e+6rtq2swMOI5F8vIomu1wVmQ2oP1Fr2bg9gKFNFUm2asgdPrLpaFA Ls4WQ5esO+HXTWL8bNfC7OkCC1jgwlqeEfxmb4uhTMNTUQ4bxw9QIJe1rBaXZduj tg4eifz6sehQuKpZ2wd14cQYB44Rm9wv13b7izzVi4Z+/tFcFaPg6bMP48i1Ryw0 U/Cuwku3/8ISY0uGNVHjuGRHNj+dCufpeZj3o9ZfE7LGErFjhyEIK7IhI9Qsj6TQ OLGImlRN/bbUc05rHOAtGRBgIoyZ/72bCwZQhuNzjItwxl744sUveLEcoUntAtjw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 776849E092; Wed, 4 Apr 2018 06:16:12 -0400 (EDT) Message-Id: <1522836972.2924642.1326063696.15670680@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-bb419338 In-Reply-To: References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> <1522752111.78362.1324712112.35AEA1A1@webmail.messagingengine.com> Date: Wed, 04 Apr 2018 11:16:12 +0100 Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 10:16:15 -0000 On Wed, 4 Apr 2018, at 3:23 AM, Martin Thomson wrote: > Is it possible to have a common tie-breaker process and force the > loser to rebase? Yes, I think so. Another one would be "the person who has least recently done an update wins ties", which would help with starvation issues. As you point out, the downside is that endpoints might have to keep quite a lot of potential state around in case an old message comes through and requires a large rebase. I was wondering whether you could have a cap like "never rebase more than five updates ago" or something to prevent that case, but the challenge there is that without a centralised server you don't have a consistent view of how many updates have actually happened. The particularly problematic case is when e.g. A and B do a whole bunch of updates, and then C comes in and preempts them. Having a centralised sequencing server makes this whole problem go away, sadly. Katriel From nobody Wed Apr 4 09:58:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DCD120724 for ; Wed, 4 Apr 2018 09:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4R4g0S0Krz1w for ; Wed, 4 Apr 2018 09:58:37 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (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 72048127978 for ; Wed, 4 Apr 2018 09:58:37 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f3lk1-0000rn-MB for mls@ietf.org; Wed, 04 Apr 2018 18:58:34 +0200 To: mls@ietf.org References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> From: Simon Friedberger Message-ID: Date: Wed, 4 Apr 2018 18:58:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 16:58:47 -0000 XMPP has long had problems with MUCs because they are used for both "group chats": private, few users, users usually constant, consistent timeline important (the Whatsapp model) "chat rooms": public, many users, users dynamic, splitting would be acceptable, transcript optional (the IRC model) In general "group chats" have the stricter requirements and are probably better served by a centralized server. I think the use-case for allowing splits is pretty weak. 1. Users mostly don't want it because it doesn't fit the model of a modern group chat where your presence in the room is independent of the connection of your devices. In fact it is essentially a case of "lost messages". Which is probably the main complaint about XMPP and Signal that I hear. 2. It seems to me it also doesn't force centralization as long as multiple servers can host chats. They would just be different chats to the user as well. Having said that, allowing p2p messengers would be great but maybe they just have to elect a leader. Supporting distributed setups is a necessity but at the level of MLS they can probably be treated as one server. Best Regards, Simon On 03.04.2018 11:29, Matthew Hodgson wrote: > Hi all, > > [TL;DR: MLS doesn't seem to support decentralisation.  Can we fix > that, especially given it'll help solve other problems too?  I have a > handwavey proposal.] > > Since IETF101 I've been trying to work out how well MLS could be > applied in fully decentralised environments which lack any single > controlling server, as it seems that the current proposal effectively > rules this out due to the state sequencing requirements (thanks to Ben > Schwartz for spelling this out to me after the BOF!). > > This feels like it could be quite a large oversight, given there are > many real-time communication protocols and services (e.g. Matrix[1], > Tox[2], Briar[3], Secure Scuttlebutt[4], Whisper[5], PSS[6], psyc2[7], > XMPP FMUCs[8] (and MIX?), even NNTP and SMTP) where messages are > replicated over a network of peers without any single controlling > server - all of which could benefit from the well specified, > interoperable & scalable group e2e encryption that MLS promises!  > There's also a more ideological argument that interoperable > communication is such a fundamental right that the IETF should support > services which support communication without a necessary central > logical point of control (much as the internet itself is decentralised). > > More practically, there may be some benefit to considering > decentralisation in MLS in general: for instance, general solutions to > races and key synchronisation within a decentralised network could > also solve races in a centralised deployment.  It could also improve > scalability and geo-redundancy by avoiding the need for an atomic > ordering system for state changes. > > To give some concrete context: all conversations in Matrix are > expressed as Merkle DAGs of messages which are replicated over the > participating servers using eventual consistency semantics (a bit like > a full mesh of Git repositories all constantly pushing commits to one > another).  As a result the conversation DAG often forks: either due to > races, partitioned networks, disconnected or offline servers etc - but > these temporary forks are very much a desirable feature, allowing > partially disconnected operation (e.g. letting a site continue > communicating locally even when isolated from the wider network), and > aiding scalability (no need for global locks or sequencing). > > Currently Matrix uses Olm[9] (a Double Ratchet Algorithm > implementation) to maintain a full mesh of secure 1:1 channels between > devices, and then shares a group ratchet (Megolm[10]) per sender over > these channels.  The megolm ratchet is a simple hash ratchet which > advances every message, and is replaced every N messages (or when > group membership changes). The cost of replacement is O(N) with the > size of the group, as is the cost of adding users to the group, which > obviously makes ART & MLS’s O(log N) behaviour appealing. > > However, the eventual consistency semantics of a decentralised > protocol introduce challenges for E2E encryption: for instance, the > membership of a given room is not well defined, as there may be a > partition of the room (either due to races or netsplit) which include > devices or users that a sender is not yet aware of.  This mandates a > way of retrospectively syncing message keys between devices after such > a fork: deliberately prioritising UX (ensuring messages that users > expect to be able to decrypt can be decrypted) over forward secrecy.  > The same mechanism can be used for cross-device history sync or > sharing history from before users join a group. > > In Matrix we solve this by letting devices share group ratchet key > state between each other over Olm by making so-called 'keyshare > requests'. Devices must have explicitly verified and trusted the > identity of the requesting device before they share keys to it (and > currently, keyshare is only supported between a given user's devices - > in future we could also support keyshare between all the group's > devices if the requester is verified and can provide a proof of > permission to view the requested content).  This obviously puts a > large onus on the device verification mechanism to ensure an attacker > isn't able to exfiltrate keys, but our experience has been that the > improved UX is worth the risk (plus can always be disabled if needed, > e.g. in a single-server centralised deployment). > > So, how can we support something like this in MLS? > > There seem to be two main obstacles: 1) the requirement for strict > sequencing of state changes, 2) the lack of keyshare semantics to > recover from the missing key data which is inevitable in an eventually > consistent view of a room.  I'm going to ignore the second for now as > it can be fixed out of band (although much like attachments, it feels > like something which MLS should make /some/ recommendation on, given > it can be incredibly useful as a primitive) > > However, for state sequencing: Am I right in saying that a race > between B and C joining a group can cause one client to see a DH > binary tree with frontier (AB, C) versus (AC, B), and thus have > inconsistent root group keys - messages encrypted during the partition > are going to inevitably be undecryptable by the other side? > > Is there a way where MLS could allow a group to recover from a > partition like this by (partially?) rebalancing the DH binary tree > into a canonical form once the partition heals?  Thus if a partition > was detected at the application layer (in Matrix's case, we'd do this > by noting that the B-join and C-join events share the same A-join > parent), the servers participating in the room would rebalance (AB,C) > and (AC,B) to both be (AB,C) and then the conversation could proceed > as normal. One might be able to avoid rebalancing the whole tree to > minimise CPU impact (although in practice healing these races are > fairly rare edge cases).  Obviously this assumes that one has a way to > request keys to recover the messages lost when the groups were out of > sync. > > If this mechanism makes sense, it seems that it could provide a way to > eliminate the "Sequencing of State Changes" requirement entirely from > MLS - or at least provide an alternative for folks where either > server-side or client-side strict sequencing isn't an option, and so > solve the general 'how to handle races' problem mentioned at the BOF > (whilst also necessitating an interoperable solution to history/key > sharing, similar to the earlier “Use cases for avoiding forward > secrecy” thread[11]) > > Anyway, apologies for the stream of consciousness - feedback from > those who properly understand ART & MLS would be hugely appreciated :) > > thanks, > > Matthew > > [1] https://matrix.org/docs/spec > [2] https://toktok.ltd/spec.html#introduction > [3] > https://code.briarproject.org/akwizgran/briar-spec/blob/master/protocols/BTP.md > [4] https://ssbc.github.io/scuttlebutt-protocol-guide/ > [5] https://github.com/ethereum/go-ethereum/wiki/Whisper > [6] https://gist.github.com/zelig/d52dab6a4509125f842bbd0dce1e9440 > [7] https://gnunet.org/sites/default/files/gnunet-psyc.pdf > [8] https://xmpp.org/extensions/xep-0289.html > [9] https://git.matrix.org/git/olm/about/docs/olm.rst > [10] https://git.matrix.org/git/olm/about/docs/megolm.rst > [11] > https://mailarchive.ietf.org/arch/msg/mls/b5YoQfdeFcoLYrFdxbZmdX__jWA > > P.S. This has probably already been fixed, but the [signal] footnote > on https://tools.ietf.org/html/draft-barnes-mls-protocol-00 is > credited to "T. and M. Marlinspike" - I think you are missing a 'Perrin'? > > From nobody Wed Apr 4 11:08:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350FE12D779 for ; Wed, 4 Apr 2018 11:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matrix.org 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 tJ7WWWVwp-S1 for ; Wed, 4 Apr 2018 11:08:45 -0700 (PDT) Received: from hermes.matrix.org (hermes.matrix.org [83.136.254.153]) (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 774EB126BFD for ; Wed, 4 Apr 2018 11:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=matrix.org; s=hermes; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=1KMPht7JuQsNZGUu7NdlWDOW1X7eMS0TnUITGA6/4oU=; b=svg55QSkHl8zku6uAkwL2Dh22Jfek6w1hRFTNx7YESc2n8zTxm8ve85zf+XnEXTJkB609Np8Yfj1YirpJrNxhNUUX52ziFqUlxvBJLKyjkZrK1kbJiPaY4t6krpKStFFcFm9JF6j+ei9l4eha+BXD++gdDbUZlMUyh8o/Lap2sYm68pHH7UF14DShtjwCi94B/m27jT0IhSIvvxD42XEfMmtESUzUuUmSzZDjYpnm+TFsXEe69F14UjqO0vx/9fTBy2XmClhOJLCeZg1rFIvN0vxkyE4fJC8HJimCdNnzf+3C/bgJLOsN+wDKeqmsn94ze4ziYbSUawPha/Yw+h5Zg==; Received: from 82-132-234-194.dab.02.net ([82.132.234.194] helo=[10.2.165.178]) by hermes.matrix.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1f3mpv-0007gb-SC; Wed, 04 Apr 2018 18:08:43 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Matthew Hodgson X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Wed, 4 Apr 2018 19:08:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6745e49d-9826-ac74-03b6-e6adbde7e805@matrix.org> To: mls@ietf.org Archived-At: Subject: Re: [MLS] MLS in decentralised environments X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 18:08:47 -0000 > On 4 Apr 2018, at 17:58, Simon Friedberger wrote: >=20 > I think the use-case for allowing splits is pretty weak. I think you have misunderstood my use of the word =E2=80=9Cnetsplit=E2=80=9D= . I was not talking about IRC style netsplits where network partitions cause= users to vanish from either side of the partition and messages to be lost. I= nstead, I=E2=80=99m talking about modern decentralised or p2p protocols like= Matrix where a network partition allows both sets of connected nodes to kee= p talking to each other... and the history is synced over to the rest of the= network when the partition is healed. No messages are lost, and it=E2=80=99= s equally valuable for public chatrooms, private group chats or 1:1 conversa= tions. Instead, it provides an eventually consistent conversation history wh= ich is immune to network races and partitions (not dissimilar to SMTP). Shor= t outages end up being completely transparent; long outages can be modelled a= s threaded conversations. For instance: =E2=80=9COh, look, the NY office jus= t fixed their internet access: there=E2=80=99s the sidebar discussion they h= ad whilst they were disconnected=E2=80=9D. > 1. Users mostly don't want it because it doesn't fit the model of a > modern group chat where your presence in the room is independent of the > connection of your devices. In fact it is essentially a case of "lost > messages". Which is probably the main complaint about XMPP and Signal > that I hear. As per above, no messages get lost. In fact the consideration here is a mech= anism to *avoid* message getting lost in the face of a network partition. >=20 > 2. It seems to me it also doesn't force centralization as long as > multiple servers can host chats. They would just be different chats to > the user as well. Having a single logical server responsible for the policy and existence of a= ny given conversation is (to me) very centralised. If that service goes down= or can=E2=80=99t scale or has bad connectivity or is somehow compromised or= broken or hosted in an environment you don=E2=80=99t trust... then you are s= crewed unless you migrate to another room, with all the social and UX disrup= tion that entails. Hence trying to ensure that conversations themselves are d= ecentralised. It=E2=80=99s the same reason that DVCSes like Git are often considered more d= esirable and flexible than centralised repos like Subversion. > Having said that, allowing p2p messengers would be great but maybe they > just have to elect a leader. Supporting distributed setups is a > necessity but at the level of MLS they can probably be treated as one > server. For the reasons given in my answer above; selecting a centralised leader for= a decentralised conversation eliminates the whole point of the conversation= being decentralised in the first place. M= From nobody Fri Apr 13 11:09:26 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3727124E15 for ; Fri, 13 Apr 2018 11:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 v-5axoj4BL-P for ; Fri, 13 Apr 2018 11:09:24 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 D416B127201 for ; Fri, 13 Apr 2018 11:09:23 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id j73so10011774qke.6 for ; Fri, 13 Apr 2018 11:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=keMyytt6HR8f3RBw19V111ZoHrSaqUijc8uKo8lm9BE=; b=mn/TxxRSk5iO1HLemzVKorPZL/VpTZc63z2JyJkWOBp573cw/9vZLVLg3tvMN55vOW jyPxPyCpSifN22M1SRIOg/divn7zUP9QDAcgxWHYKh+Gcd+zCo93rHnAygUqG1POwYxl jajC2pZkpu/48oEHCw/PcBmryfIPo6HWCVevI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=keMyytt6HR8f3RBw19V111ZoHrSaqUijc8uKo8lm9BE=; b=nxR5Yr5nno7m8c2LtmPEav3l+wUSgnLCxbqhoNFcqkUk7AYS523/74Rlop5bBt17In qW5Q5TUg9vN1Z6NuW3IbySWuT4DuIzGwlrDwye1VfvKBpObL4bziFfdE7S8TvSfYq5xK /2QEbo9ZNFSuPlZmnrOxdk094fM5H5PehCcn0rDylH2rdvH0xl4qNQGdrGpSsoLF2pms iWlXL9KJCcK5chRLlRTeMbbUcs9KAIAc8dAHkVNbgRuNwVOCv2PFRJwH6WszSyl14N8f YnqyNrhX/kVEWjcVGk3RithZs0+tuQ7yU1C+TgCzN1+Ntgxgyj6PBrNwNqu7yNci0yko /RLg== X-Gm-Message-State: ALQs6tCjk97WIPSQFA+5dQnb8NISudjor/b5fZwkKUMtTJXb4pY7WsN9 0/qydks6Gd65fOCsJ0sXIJ9gGzUu9Os= X-Google-Smtp-Source: AIpwx4/SepWxWeErO8HJig19pX7RX1eYw0KMl8qQabVy1gLTWF4EC9S6sbfqBHsizGuLlBTDuOg8hw== X-Received: by 10.55.110.4 with SMTP id j4mr5635135qkc.272.1523642962644; Fri, 13 Apr 2018 11:09:22 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id 24sm5710256qkv.41.2018.04.13.11.09.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 11:09:21 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: Date: Fri, 13 Apr 2018 14:09:20 -0400 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 18:09:26 -0000 All, The charter tweaks made since the BOF include tweaking (and reordering) = some of the =E2=80=9Cproperty=E2=80=9D bullets: - added message confidentiality - message authentication changed to message integrity and authentication I know that Ben Schwartz mentioned that we should look at our =E2=80=9Cful= l compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99s= used in FS and PCS property bullets it looks okay to me. But, maybe = Ben can elaborate a bit. Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: Messaging Layer Security (MLS) Charter (DRAFT) Several Internet applications have a need for group key establishment and message protection protocols with the following properties: o Message Confidentiality - Messages can only be read by members of the group o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with o Membership Authentication - Each participant can verify the set of members in the group o Asynchronicity - Keys can be established without any two participants being online at the same time o Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the group o Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the group o Scalability - Resource requirements that have good scaling in the size of the group (preferably sub-linear) Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3).=20 It is not a goal of this group to enable interoperability / federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs. While authentication is a key goal of this working group, it is not the objective of this working group to develop new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications: o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 o Off the Record - =E2=80=8Bhttps://otr.cypherpunks.ca/Protocol-v3-4.1.1.h= tml o Signal - =E2=80=8Bhttps://signal.org/docs/ The intent of this working group is to follow the pattern of TLS 1.3, with specification, implementation, and verification proceeding in parallel. By the time we arrive at RFC, we hope to have several interoperable implementations as well as a thorough security analysis. The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, and generalizing the design described in: o draft-omara-mls-architecture o draft-barnes-mls-protocol Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. Milestones: May 2018 - Initial working group documents for architecture and key = management Sept 2018 - Initial working group document adopted for message = protection Jan 2019 - Submit architecture document to IESG as Informational Jun 2019 - Submit key management protocol to IESG as Proposed Standard Sept 2019 - Submit message protection protocol to IESG as Proposed = Standard Cheers, spt= From nobody Fri Apr 13 11:52:37 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37B8127775 for ; Fri, 13 Apr 2018 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 81n9kRyF9QD4 for ; Fri, 13 Apr 2018 11:52:33 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 57679127601 for ; Fri, 13 Apr 2018 11:52:33 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id a25so2780985qtm.1 for ; Fri, 13 Apr 2018 11:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Aqk19AdIRUpDJqy0GoWtbL3tYB8WgzRdRrrAsOx9fps=; b=kAut5+rQ7IWZo8SACLa5OIQXTNrwl5lV0akLyO+BBykUAqgColbx/f+LlNi2XwIgi7 a2EWzSwXKlLq7iq3J92WNi4/ut+P5ve1Us2HttNkNNLEoNfmxOWnta4gf+9ThAmWhnae zaKdROSDJqc3bWCPKA0ZwA53ynsvQvE9Ve/oU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Aqk19AdIRUpDJqy0GoWtbL3tYB8WgzRdRrrAsOx9fps=; b=Q/g+G5EPfVaul0a7KaFqp/MmHPrdCAXq6HzDub1Q3EfXUt45xcJDAf9tecdMWDAcwc WcL4CFT/zhPwZvAFU/Sb1s2b9Y8ON655uPYfjltB+fvzM9235K2sCb1MfkVLZdjj+SEI NnxJ6mV2Ys4zuKux5D8hmxImifbfHoDWyx40wkLarBRq4/K4cBSuTVu7Su9HRmABHmoS J3/gETdoG9GmryoafzWhRy8lkigu2af9v5uSROnAkwqfpH8R7KLooElSFLWHFTTFOfoS DEjFCKejlEVS+CvX9gUMs7i2OyyB7F6ovy9Y07YFNBqd6iWUwHJndq8zwM5gmWy5pSD2 ZObg== X-Gm-Message-State: ALQs6tBy3jTDg7LxlInw132VrUVyglVwVocwq3QPA3U/2VCsTS7TZ5Km viS1OwEmhrvz394vVPWp+8psAmklJxQ= X-Google-Smtp-Source: AIpwx49t1W/YuYciWb9zuJLj3YalfyU5vxwEGkgpvBNUPX7fpHw7pWgt9BHSyMauBz7qPGlml6qG0w== X-Received: by 10.200.17.149 with SMTP id d21mr4517851qtj.256.1523645552183; Fri, 13 Apr 2018 11:52:32 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id b13sm2319672qtp.77.2018.04.13.11.52.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Apr 2018 11:52:31 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 13 Apr 2018 14:52:30 -0400 References: To: mls@ietf.org In-Reply-To: Message-Id: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2018 18:52:36 -0000 Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t get = copied over: Messaging Layer Security (MLS) Charter (DRAFT) Several Internet applications have a need for group key establishment and message protection protocols with the following properties: o Message Confidentiality - Messages can only be read by members of the group o Message Integrity and Authentication - Each message has been sent by an authenticated sender, and has not been tampered with o Membership Authentication - Each participant can verify the set of members in the group o Asynchronicity - Keys can be established without any two participants being online at the same time o Forward secrecy - Full compromise of a node at a point in time does not reveal past messages sent within the group o Post-compromise security - Full compromise of a node at a point in time does not reveal future messages sent within the group o Scalability - Resource requirements have good scaling in the size of the group (preferably sub-linear) Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3).=20 It is not a goal of this group to enable interoperability / federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security, e.g., standard message transport and application semantics. The focus of this work is to develop a messaging security layer that different applications can adapt to their own needs. While authentication is a key goal of this working group, it is not the objective of this working group to develop new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. In developing this protocol, we will draw on lessons learned from several prior message-oriented security protocols, in addition to the proprietary messaging security protocols deployed within existing applications: o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 o Off the Record - =E2=80=8Bhttps://otr.cypherpunks.ca/Protocol-v3-4.1.1.h= tml o Signal - =E2=80=8Bhttps://signal.org/docs/ The intent of this working group is to follow the pattern of TLS 1.3, with specification, implementation, and verification proceeding in parallel. By the time we arrive at RFC, we hope to have several interoperable implementations as well as a thorough security analysis. The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, generalizing the design described in: o draft-omara-mls-architecture o draft-barnes-mls-protocol Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. Milestones: May 2018 - Initial working group documents for architecture and key = management Sept 2018 - Initial working group document adopted for message = protection Jan 2019 - Submit architecture document to IESG as Informational Jun 2019 - Submit key management protocol to IESG as Proposed Standard Sept 2019 - Submit message protection protocol to IESG as Proposed = Standard Cheers, spt > On Apr 13, 2018, at 14:09, Sean Turner wrote: >=20 > All, >=20 > The charter tweaks made since the BOF include tweaking (and = reordering) some of the =E2=80=9Cproperty=E2=80=9D bullets: > - added message confidentiality > - message authentication changed to message integrity and = authentication >=20 > I know that Ben Schwartz mentioned that we should look at our =E2=80=9Cf= ull compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99= s used in FS and PCS property bullets it looks okay to me. But, maybe = Ben can elaborate a bit. >=20 > Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: >=20 >=20 > Messaging Layer Security (MLS) Charter (DRAFT) >=20 > Several Internet applications have a need for group key establishment > and message protection protocols with the following properties: >=20 > o Message Confidentiality - Messages can only be read > by members of the group > o Message Integrity and Authentication - Each message > has been sent by an authenticated sender, and has > not been tampered with > o Membership Authentication - Each participant can verify > the set of members in the group > o Asynchronicity - Keys can be established without any > two participants being online at the same time > o Forward secrecy - Full compromise of a node at a point > in time does not reveal past messages sent within the group > o Post-compromise security - Full compromise of a node at a > point in time does not reveal future messages sent within the group > o Scalability - Resource requirements that have good scaling in the > size of the group (preferably sub-linear) >=20 > Several widely-deployed applications have developed their own > protocols to meet these needs. While these protocols are similar, > no two are close enough to interoperate. As a result, each application > vendor has had to maintain their own protocol stack and independently > build trust in the quality of the protocol. The primary goal of this > working group is to develop a standard messaging security protocol > so that applications can share code, and so that there can be shared > validation of the protocol (as there has been with TLS 1.3).=20 >=20 > It is not a goal of this group to enable interoperability / federation > between messaging applications beyond the key establishment, > authentication, and confidentiality services. Full interoperability > would require alignment at many different layers beyond security, > e.g., standard message transport and application semantics. The > focus of this work is to develop a messaging security layer that > different applications can adapt to their own needs. >=20 > While authentication is a key goal of this working group, it is not > the objective of this working group to develop new authentication > technologies. Rather, the security protocol developed by this > group will provide a way to leverage existing authentication > technologies to associate identities with keys used in the protocol, > just as TLS does with X.509. >=20 > In developing this protocol, we will draw on lessons learned from > several prior message-oriented security protocols, in addition to > the proprietary messaging security protocols deployed within > existing applications: >=20 > o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 > o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 > o Off the Record - = =E2=80=8Bhttps://otr.cypherpunks.ca/Protocol-v3-4.1.1.html > o Signal - =E2=80=8Bhttps://signal.org/docs/ >=20 > The intent of this working group is to follow the pattern of > TLS 1.3, with specification, implementation, and verification > proceeding in parallel. By the time we arrive at RFC, we > hope to have several interoperable implementations as well > as a thorough security analysis. >=20 > The specifications developed by this working group will be > based on pre-standardization implementation and deployment > experience, and generalizing the design described in: >=20 > o draft-omara-mls-architecture > o draft-barnes-mls-protocol >=20 > Note that consensus is required both for changes to the current > protocol mechanisms and retention of current mechanisms. In > particular, because something is in the initial document set does > not imply that there is consensus around the feature or around > how it is specified. >=20 > Milestones: > May 2018 - Initial working group documents for architecture and key = management > Sept 2018 - Initial working group document adopted for message = protection > Jan 2019 - Submit architecture document to IESG as Informational > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > Sept 2019 - Submit message protection protocol to IESG as Proposed = Standard >=20 > Cheers, >=20 > spt From nobody Wed Apr 18 08:18:38 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED74127337 for ; Wed, 18 Apr 2018 08:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 Ey-lOU7WNA7H for ; Wed, 18 Apr 2018 08:18:33 -0700 (PDT) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 F259B126BF3 for ; Wed, 18 Apr 2018 08:18:32 -0700 (PDT) Received: by mail-ot0-x22b.google.com with SMTP id h55-v6so2310071ote.9 for ; Wed, 18 Apr 2018 08:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Myq9YQ8EHi08EqOJuj3TdoQxxW76BMNbIZBpl/XzvAE=; b=ybvtUVLBaqfvmZ2UJS7P2RqSzhrPgoC4x+eWc1JBLoq3kn3VSXoEPbPATXKQYu0SvL SwtNSCzOPdG1beK5B/wcKVuCdYeh2e9pO6TsTOmdDS3i0tebm4LR/DB7LWw59WpEP1iE K3zF6lrOLFg2QmzJdDvcT3avjy4gkqqRuF168dGEYq0DbY9iDfFMvICF1W/qgcvdUgsn x1x8XdPcyqWtt+VRuZILHjU1Fs7TWeaAheK+pcvtKqwEgyQTkh8jPHqz84ZiImAZCUQ9 IyZaGluudltkwzhQRz+tG4y7INOA7tToPS0Va9++FfIMz091MtsEPQpHaJs8XuDrkQgm 1gSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Myq9YQ8EHi08EqOJuj3TdoQxxW76BMNbIZBpl/XzvAE=; b=pm2/9fFySxoe+7S0f2quHOqHlZzm8X87V2WfMiwUGzdO6ThCTc/VOEFC0q8p//SL2u 8ibehKmafOTrzgThfzmrPaXYlllis1+47NzdDO6x1qUMETIYycw0lzcTEdFoIe8POJGS EP/AEiYhMR/g/ipo4rm0rQZrStkdGb0Bsa/WIIrUwFXCIu/+7FLpU3m4yZWz0u3eKHnu x5LUTm2yXuBdIq+RYxfjWao0v4g/D9vbMCvws2KQNA5jCG05mn+Tlui/5+rBMz8n3lzm 9j8XPDZTVsOL6gqFwOFBhaSgevKBBDMjfVgc5L/vi8F1P0KmBJzwnDf+ACg2KF5kGtxU gW7g== X-Gm-Message-State: ALQs6tAUHsBF+0mDqlEhjhdKoJKlWrvWEzBw8tJZkdfQC3kc3063RXth dVvDHMxlSjkLGdtz4H1LfBBips938sxqTH1oLTc5hiwC X-Google-Smtp-Source: AIpwx4+t1ggXBTLYxZ7+fVdK2TpAs71AF7Ih+CaU/0jqFcvG7Br3IMlXbV4xP0FyMZIdzWHaz6eaTIKdIu1Jtc+HG58= X-Received: by 2002:a9d:5403:: with SMTP id j3-v6mr1644710oth.52.1524064712030; Wed, 18 Apr 2018 08:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.93.90 with HTTP; Wed, 18 Apr 2018 08:18:31 -0700 (PDT) In-Reply-To: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> From: Richard Barnes Date: Wed, 18 Apr 2018 11:18:31 -0400 Message-ID: To: Sean Turner Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000c69167056a20f788" Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:18:36 -0000 --000000000000c69167056a20f788 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Sean, This looks good to me. Ship it. --Richard On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner wrote: > Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t get cop= ied over: > > Messaging Layer Security (MLS) Charter (DRAFT) > > Several Internet applications have a need for group key establishment > and message protection protocols with the following properties: > > o Message Confidentiality - Messages can only be read > by members of the group > o Message Integrity and Authentication - Each message > has been sent by an authenticated sender, and has > not been tampered with > o Membership Authentication - Each participant can verify > the set of members in the group > o Asynchronicity - Keys can be established without any > two participants being online at the same time > o Forward secrecy - Full compromise of a node at a point > in time does not reveal past messages sent within the group > o Post-compromise security - Full compromise of a node at a > point in time does not reveal future messages sent within the group > o Scalability - Resource requirements have good scaling in the > size of the group (preferably sub-linear) > > Several widely-deployed applications have developed their own > protocols to meet these needs. While these protocols are similar, > no two are close enough to interoperate. As a result, each application > vendor has had to maintain their own protocol stack and independently > build trust in the quality of the protocol. The primary goal of this > working group is to develop a standard messaging security protocol > so that applications can share code, and so that there can be shared > validation of the protocol (as there has been with TLS 1.3). > > It is not a goal of this group to enable interoperability / federation > between messaging applications beyond the key establishment, > authentication, and confidentiality services. Full interoperability > would require alignment at many different layers beyond security, > e.g., standard message transport and application semantics. The > focus of this work is to develop a messaging security layer that > different applications can adapt to their own needs. > > While authentication is a key goal of this working group, it is not > the objective of this working group to develop new authentication > technologies. Rather, the security protocol developed by this > group will provide a way to leverage existing authentication > technologies to associate identities with keys used in the protocol, > just as TLS does with X.509. > > In developing this protocol, we will draw on lessons learned from > several prior message-oriented security protocols, in addition to > the proprietary messaging security protocols deployed within > existing applications: > > o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 > o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 > o Off the Record - =E2=80=8Bhttps://otr.cypherpunks.ca/Protocol-v3-4.1.1.= html > o Signal - =E2=80=8Bhttps://signal.org/docs/ > > The intent of this working group is to follow the pattern of > TLS 1.3, with specification, implementation, and verification > proceeding in parallel. By the time we arrive at RFC, we > hope to have several interoperable implementations as well > as a thorough security analysis. > > The specifications developed by this working group will be > based on pre-standardization implementation and deployment > experience, generalizing the design described in: > > o draft-omara-mls-architecture > o draft-barnes-mls-protocol > > Note that consensus is required both for changes to the current > protocol mechanisms and retention of current mechanisms. In > particular, because something is in the initial document set does > not imply that there is consensus around the feature or around > how it is specified. > > Milestones: > May 2018 - Initial working group documents for architecture and key > management > Sept 2018 - Initial working group document adopted for message protection > Jan 2019 - Submit architecture document to IESG as Informational > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > Sept 2019 - Submit message protection protocol to IESG as Proposed Standa= rd > > Cheers, > > spt > > > On Apr 13, 2018, at 14:09, Sean Turner wrote: > > > > All, > > > > The charter tweaks made since the BOF include tweaking (and reordering) > some of the =E2=80=9Cproperty=E2=80=9D bullets: > > - added message confidentiality > > - message authentication changed to message integrity and authenticatio= n > > > > I know that Ben Schwartz mentioned that we should look at our =E2=80=9C= full > compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99s = used in FS and PCS > property bullets it looks okay to me. But, maybe Ben can elaborate a bit= . > > > > Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: > > > > > > Messaging Layer Security (MLS) Charter (DRAFT) > > > > Several Internet applications have a need for group key establishment > > and message protection protocols with the following properties: > > > > o Message Confidentiality - Messages can only be read > > by members of the group > > o Message Integrity and Authentication - Each message > > has been sent by an authenticated sender, and has > > not been tampered with > > o Membership Authentication - Each participant can verify > > the set of members in the group > > o Asynchronicity - Keys can be established without any > > two participants being online at the same time > > o Forward secrecy - Full compromise of a node at a point > > in time does not reveal past messages sent within the group > > o Post-compromise security - Full compromise of a node at a > > point in time does not reveal future messages sent within the group > > o Scalability - Resource requirements that have good scaling in the > > size of the group (preferably sub-linear) > > > > Several widely-deployed applications have developed their own > > protocols to meet these needs. While these protocols are similar, > > no two are close enough to interoperate. As a result, each application > > vendor has had to maintain their own protocol stack and independently > > build trust in the quality of the protocol. The primary goal of this > > working group is to develop a standard messaging security protocol > > so that applications can share code, and so that there can be shared > > validation of the protocol (as there has been with TLS 1.3). > > > > It is not a goal of this group to enable interoperability / federation > > between messaging applications beyond the key establishment, > > authentication, and confidentiality services. Full interoperability > > would require alignment at many different layers beyond security, > > e.g., standard message transport and application semantics. The > > focus of this work is to develop a messaging security layer that > > different applications can adapt to their own needs. > > > > While authentication is a key goal of this working group, it is not > > the objective of this working group to develop new authentication > > technologies. Rather, the security protocol developed by this > > group will provide a way to leverage existing authentication > > technologies to associate identities with keys used in the protocol, > > just as TLS does with X.509. > > > > In developing this protocol, we will draw on lessons learned from > > several prior message-oriented security protocols, in addition to > > the proprietary messaging security protocols deployed within > > existing applications: > > > > o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 > > o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 > > o Off the Record - =E2=80=8Bhttps://otr.cypherpunks.ca/Protocol-v3-4.1.= 1.html > > o Signal - =E2=80=8Bhttps://signal.org/docs/ > > > > The intent of this working group is to follow the pattern of > > TLS 1.3, with specification, implementation, and verification > > proceeding in parallel. By the time we arrive at RFC, we > > hope to have several interoperable implementations as well > > as a thorough security analysis. > > > > The specifications developed by this working group will be > > based on pre-standardization implementation and deployment > > experience, and generalizing the design described in: > > > > o draft-omara-mls-architecture > > o draft-barnes-mls-protocol > > > > Note that consensus is required both for changes to the current > > protocol mechanisms and retention of current mechanisms. In > > particular, because something is in the initial document set does > > not imply that there is consensus around the feature or around > > how it is specified. > > > > Milestones: > > May 2018 - Initial working group documents for architecture and key > management > > Sept 2018 - Initial working group document adopted for message protecti= on > > Jan 2019 - Submit architecture document to IESG as Informational > > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > > Sept 2019 - Submit message protection protocol to IESG as Proposed > Standard > > > > Cheers, > > > > spt > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c69167056a20f788 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Sean,

This looks good to= me.=C2=A0 Ship it.

--Richard

On Fri, Apr 13, 2018 a= t 2:52 PM, Sean Turner <sean@sn3rd.com> wrote:
Sorry I missed to minor edits from Jonathan Lennox didn= =E2=80=99t get copied over:

Messaging Layer Security (MLS) Charter (DRAFT)

Several Internet applications have a need for group key establishment
and message protection protocols with the following properties:

o Message Confidentiality - Messages can only be read
=C2=A0 by members of the group
o Message Integrity and Authentication - Each message
=C2=A0 has been sent by an authenticated sender, and has
=C2=A0 not been tampered with
o Membership Authentication - Each participant can verify
=C2=A0 the set of members in the group
o Asynchronicity - Keys can be established without any
=C2=A0 two participants being online at the same time
o Forward secrecy - Full compromise of a node at a point
=C2=A0 in time does not reveal past messages sent within the group
o Post-compromise security - Full compromise of a node at a
=C2=A0 point in time does not reveal future messages sent within the group<= br> o Scalability - Resource requirements have good scaling in the
=C2=A0 size of the group (preferably sub-linear)

Several widely-deployed applications have developed their own
protocols to meet these needs. While these protocols are similar,
no two are close enough to interoperate. As a result, each application
vendor has had to maintain their own protocol stack and independently
build trust in the quality of the protocol. The primary goal of this
working group is to develop a standard messaging security protocol
so that applications can share code, and so that there can be shared
validation of the protocol (as there has been with TLS 1.3).

It is not a goal of this group to enable interoperability / federation
between messaging applications beyond the key establishment,
authentication, and confidentiality services.=C2=A0 Full interoperability would require alignment at many different layers beyond security,
e.g., standard message transport and application semantics.=C2=A0 The
focus of this work is to develop a messaging security layer that
different applications can adapt to their own needs.

While authentication is a key goal of this working group, it is not
the objective of this working group to develop new authentication
technologies.=C2=A0 Rather, the security protocol developed by this
group will provide a way to leverage existing authentication
technologies to associate identities with keys used in the protocol,
just as TLS does with X.509.

In developing this protocol, we will draw on lessons learned from
several prior message-oriented security protocols, in addition to
the proprietary messaging security protocols deployed within
existing applications:

o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751<= br> o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880=
o Off the Record - =E2=80=8Bhttps://otr.cypherpunks= .ca/Protocol-v3-4.1.1.html
o Signal - =E2=80=8Bhttps://signal.org/docs/

The intent of this working group is to follow the pattern of
TLS 1.3, with specification, implementation, and verification
proceeding in parallel.=C2=A0 By the time we arrive at RFC, we
hope to have several interoperable implementations as well
as a thorough security analysis.

The specifications developed by this working group will be
based on pre-standardization implementation and deployment
experience, generalizing the design described in:

o draft-omara-mls-architecture
o draft-barnes-mls-protocol

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In
particular, because something is in the initial document set does
not imply that there is consensus around the feature or around
how it is specified.

Milestones:
May 2018 - Initial working group documents for architecture and key managem= ent
Sept 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational
Jun 2019 - Submit key management protocol to IESG as Proposed Standard
Sept 2019 - Submit message protection protocol to IESG as Proposed Standard=

Cheers,

spt

> On Apr 13, 2018, at 14:= 09, Sean Turner <sean@sn3rd.com>= ; wrote:
>
> All,
>
> The charter tweaks made since the BOF include tweaking (and reordering= ) some of the =E2=80=9Cproperty=E2=80=9D bullets:
> - added message confidentiality
> - message authentication changed to message integrity and authenticati= on
>
> I know that Ben Schwartz mentioned that we should look at our =E2=80= =9Cfull compromise=E2=80=9D definition, but in reviewing it the way it=E2= =80=99s used in FS and PCS property bullets it looks okay to me.=C2=A0 But,= maybe Ben can elaborate a bit.
>
> Anyway at this point, here=E2=80=99s what we=E2=80=99re working with:<= br> >
>
> Messaging Layer Security (MLS) Charter (DRAFT)
>
> Several Internet applications have a need for group key establishment<= br> > and message protection protocols with the following properties:
>
> o Message Confidentiality - Messages can only be read
>=C2=A0 =C2=A0by members of the group
> o Message Integrity and Authentication - Each message
>=C2=A0 =C2=A0has been sent by an authenticated sender, and has
>=C2=A0 =C2=A0not been tampered with
> o Membership Authentication - Each participant can verify
>=C2=A0 =C2=A0the set of members in the group
> o Asynchronicity - Keys can be established without any
>=C2=A0 =C2=A0two participants being online at the same time
> o Forward secrecy - Full compromise of a node at a point
>=C2=A0 =C2=A0in time does not reveal past messages sent within the grou= p
> o Post-compromise security - Full compromise of a node at a
>=C2=A0 =C2=A0point in time does not reveal future messages sent within = the group
> o Scalability - Resource requirements that have good scaling in the >=C2=A0 =C2=A0size of the group (preferably sub-linear)
>
> Several widely-deployed applications have developed their own
> protocols to meet these needs. While these protocols are similar,
> no two are close enough to interoperate. As a result, each application=
> vendor has had to maintain their own protocol stack and independently<= br> > build trust in the quality of the protocol. The primary goal of this > working group is to develop a standard messaging security protocol
> so that applications can share code, and so that there can be shared > validation of the protocol (as there has been with TLS 1.3).
>
> It is not a goal of this group to enable interoperability / federation=
> between messaging applications beyond the key establishment,
> authentication, and confidentiality services.=C2=A0 Full interoperabil= ity
> would require alignment at many different layers beyond security,
> e.g., standard message transport and application semantics.=C2=A0 The<= br> > focus of this work is to develop a messaging security layer that
> different applications can adapt to their own needs.
>
> While authentication is a key goal of this working group, it is not > the objective of this working group to develop new authentication
> technologies.=C2=A0 Rather, the security protocol developed by this > group will provide a way to leverage existing authentication
> technologies to associate identities with keys used in the protocol, > just as TLS does with X.509.
>
> In developing this protocol, we will draw on lessons learned from
> several prior message-oriented security protocols, in addition to
> the proprietary messaging security protocols deployed within
> existing applications:
>
> o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751=
> o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc488= 0
> o Off the Record - =E2=80=8Bhttps://otr.cypher= punks.ca/Protocol-v3-4.1.1.html
> o Signal - =E2=80=8Bhttps://signal.org/docs/
>
> The intent of this working group is to follow the pattern of
> TLS 1.3, with specification, implementation, and verification
> proceeding in parallel.=C2=A0 By the time we arrive at RFC, we
> hope to have several interoperable implementations as well
> as a thorough security analysis.
>
> The specifications developed by this working group will be
> based on pre-standardization implementation and deployment
> experience, and generalizing the design described in:
>
> o draft-omara-mls-architecture
> o draft-barnes-mls-protocol
>
> Note that consensus is required both for changes to the current
> protocol mechanisms and retention of current mechanisms. In
> particular, because something is in the initial document set does
> not imply that there is consensus around the feature or around
> how it is specified.
>
> Milestones:
> May 2018 - Initial working group documents for architecture and key ma= nagement
> Sept 2018 - Initial working group document adopted for message protect= ion
> Jan 2019 - Submit architecture document to IESG as Informational
> Jun 2019 - Submit key management protocol to IESG as Proposed Standard=
> Sept 2019 - Submit message protection protocol to IESG as Proposed Sta= ndard
>
> Cheers,
>
> spt

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

--000000000000c69167056a20f788-- From nobody Wed Apr 18 08:39:11 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFA127522 for ; Wed, 18 Apr 2018 08:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 yNGHnQkn6zwF for ; Wed, 18 Apr 2018 08:39:07 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 EF3A01243F3 for ; Wed, 18 Apr 2018 08:39:06 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id r7-v6so3341827lfr.1 for ; Wed, 18 Apr 2018 08:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7fWWUod0Lq3oqEMAt8IYc41LtJ+D5PiR4uIw3GLJCbI=; b=GrBedaTSlttMlICqYr7EAU08gN5jFEV40mI5wPE6/RcFuekP9dVz8WUGXRJk5QkxH3 B/o4ubdU39OJQvmbyOmTZkxsnrk4TynnkrOjq2o4uCMiQzU/v6jNI5oj2lTSX0V44IYQ qv5x36hJE/GkcYF/KJZ2JZ1Txi/u5sGXHoC9g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7fWWUod0Lq3oqEMAt8IYc41LtJ+D5PiR4uIw3GLJCbI=; b=TvftoSoAncOH3743tH4AIHfwdBC/nbyX46+tjy6XHw0GJnizn2Mu0sZTT61TzHwAoo OnxwDRYYJD2W3KWuNLyklMjzWc4gxC7wIk2RmgLnp8PXeOUlRYPUhKvQmys992teke5z wDZcb6n8hond+Fg0Qgb2/v+QG6YWp9FQ5GVH3GgOnC2YpS8+q6miK8M+c67Gw6MNUb3m zTvfro6lIFv5ERnlxmRmICRNKVboHt9nQbapOGEa7JQ5HQK9yXXsNxFw/1C+fcA8PRZS qmiW9R1hMjPCJQiQrQS+nwt5ampw78fnydy3mYoKCsJ2gxxzQawgv3oVzHVSbb1dqGhj KBOA== X-Gm-Message-State: ALQs6tB2ej1spSKeYxBcgBSUQOJxcIiv0XT6gINXegmYusXdvABcWS+b 8NkB08eRhVRMS6aTwvurdsUeNiq/Uxx666Y8jSa/FA== X-Google-Smtp-Source: AIpwx4+vkSTMsVC9wIT9XmxJb0Fy8drnAqqbrn17RpHzuRILtm9rxn1kjNGSU+2xhW+yTZ4UUlzcnBNa0X5H2YNMB24= X-Received: by 10.46.46.10 with SMTP id u10mr1756043lju.77.1524065944800; Wed, 18 Apr 2018 08:39:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.71.202 with HTTP; Wed, 18 Apr 2018 08:39:04 -0700 (PDT) In-Reply-To: References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> From: Dave Cridland Date: Wed, 18 Apr 2018 16:39:04 +0100 Message-ID: To: Richard Barnes Cc: Sean Turner , mls@ietf.org Content-Type: multipart/alternative; boundary="089e0823f834413639056a214191" Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:39:10 -0000 --089e0823f834413639056a214191 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable LGTM. On 18 April 2018 at 16:18, Richard Barnes wrote: > Hey Sean, > > This looks good to me. Ship it. > > --Richard > > On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner wrote: > >> Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t get co= pied over: >> >> Messaging Layer Security (MLS) Charter (DRAFT) >> >> Several Internet applications have a need for group key establishment >> and message protection protocols with the following properties: >> >> o Message Confidentiality - Messages can only be read >> by members of the group >> o Message Integrity and Authentication - Each message >> has been sent by an authenticated sender, and has >> not been tampered with >> o Membership Authentication - Each participant can verify >> the set of members in the group >> o Asynchronicity - Keys can be established without any >> two participants being online at the same time >> o Forward secrecy - Full compromise of a node at a point >> in time does not reveal past messages sent within the group >> o Post-compromise security - Full compromise of a node at a >> point in time does not reveal future messages sent within the group >> o Scalability - Resource requirements have good scaling in the >> size of the group (preferably sub-linear) >> >> Several widely-deployed applications have developed their own >> protocols to meet these needs. While these protocols are similar, >> no two are close enough to interoperate. As a result, each application >> vendor has had to maintain their own protocol stack and independently >> build trust in the quality of the protocol. The primary goal of this >> working group is to develop a standard messaging security protocol >> so that applications can share code, and so that there can be shared >> validation of the protocol (as there has been with TLS 1.3). >> >> It is not a goal of this group to enable interoperability / federation >> between messaging applications beyond the key establishment, >> authentication, and confidentiality services. Full interoperability >> would require alignment at many different layers beyond security, >> e.g., standard message transport and application semantics. The >> focus of this work is to develop a messaging security layer that >> different applications can adapt to their own needs. >> >> While authentication is a key goal of this working group, it is not >> the objective of this working group to develop new authentication >> technologies. Rather, the security protocol developed by this >> group will provide a way to leverage existing authentication >> technologies to associate identities with keys used in the protocol, >> just as TLS does with X.509. >> >> In developing this protocol, we will draw on lessons learned from >> several prior message-oriented security protocols, in addition to >> the proprietary messaging security protocols deployed within >> existing applications: >> >> o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 >> o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 >> o Off the Record - =E2=80=8Bhttps://otr.cypherpunks..ca/Protocol-v3-4.1.= 1.html >> >> >> o Signal - =E2=80=8Bhttps://signal.org/docs/ >> >> The intent of this working group is to follow the pattern of >> TLS 1.3, with specification, implementation, and verification >> proceeding in parallel. By the time we arrive at RFC, we >> hope to have several interoperable implementations as well >> as a thorough security analysis. >> >> The specifications developed by this working group will be >> based on pre-standardization implementation and deployment >> experience, generalizing the design described in: >> >> o draft-omara-mls-architecture >> o draft-barnes-mls-protocol >> >> Note that consensus is required both for changes to the current >> protocol mechanisms and retention of current mechanisms. In >> particular, because something is in the initial document set does >> not imply that there is consensus around the feature or around >> how it is specified. >> >> Milestones: >> May 2018 - Initial working group documents for architecture and key >> management >> Sept 2018 - Initial working group document adopted for message protectio= n >> Jan 2019 - Submit architecture document to IESG as Informational >> Jun 2019 - Submit key management protocol to IESG as Proposed Standard >> Sept 2019 - Submit message protection protocol to IESG as Proposed >> Standard >> >> Cheers, >> >> spt >> >> > On Apr 13, 2018, at 14:09, Sean Turner wrote: >> > >> > All, >> > >> > The charter tweaks made since the BOF include tweaking (and reordering= ) >> some of the =E2=80=9Cproperty=E2=80=9D bullets: >> > - added message confidentiality >> > - message authentication changed to message integrity and authenticati= on >> > >> > I know that Ben Schwartz mentioned that we should look at our =E2=80= =9Cfull >> compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99s= used in FS and PCS >> property bullets it looks okay to me. But, maybe Ben can elaborate a bi= t. >> > >> > Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: >> > >> > >> > Messaging Layer Security (MLS) Charter (DRAFT) >> > >> > Several Internet applications have a need for group key establishment >> > and message protection protocols with the following properties: >> > >> > o Message Confidentiality - Messages can only be read >> > by members of the group >> > o Message Integrity and Authentication - Each message >> > has been sent by an authenticated sender, and has >> > not been tampered with >> > o Membership Authentication - Each participant can verify >> > the set of members in the group >> > o Asynchronicity - Keys can be established without any >> > two participants being online at the same time >> > o Forward secrecy - Full compromise of a node at a point >> > in time does not reveal past messages sent within the group >> > o Post-compromise security - Full compromise of a node at a >> > point in time does not reveal future messages sent within the group >> > o Scalability - Resource requirements that have good scaling in the >> > size of the group (preferably sub-linear) >> > >> > Several widely-deployed applications have developed their own >> > protocols to meet these needs. While these protocols are similar, >> > no two are close enough to interoperate. As a result, each application >> > vendor has had to maintain their own protocol stack and independently >> > build trust in the quality of the protocol. The primary goal of this >> > working group is to develop a standard messaging security protocol >> > so that applications can share code, and so that there can be shared >> > validation of the protocol (as there has been with TLS 1.3). >> > >> > It is not a goal of this group to enable interoperability / federation >> > between messaging applications beyond the key establishment, >> > authentication, and confidentiality services. Full interoperability >> > would require alignment at many different layers beyond security, >> > e.g., standard message transport and application semantics. The >> > focus of this work is to develop a messaging security layer that >> > different applications can adapt to their own needs. >> > >> > While authentication is a key goal of this working group, it is not >> > the objective of this working group to develop new authentication >> > technologies. Rather, the security protocol developed by this >> > group will provide a way to leverage existing authentication >> > technologies to associate identities with keys used in the protocol, >> > just as TLS does with X.509. >> > >> > In developing this protocol, we will draw on lessons learned from >> > several prior message-oriented security protocols, in addition to >> > the proprietary messaging security protocols deployed within >> > existing applications: >> > >> > o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751 >> > o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880 >> > o Off the Record - =E2=80=8Bhttps://otr.cypherpunks.ca/Protocol-v3-4.1= .1.html >> > o Signal - =E2=80=8Bhttps://signal.org/docs/ >> > >> > The intent of this working group is to follow the pattern of >> > TLS 1.3, with specification, implementation, and verification >> > proceeding in parallel. By the time we arrive at RFC, we >> > hope to have several interoperable implementations as well >> > as a thorough security analysis. >> > >> > The specifications developed by this working group will be >> > based on pre-standardization implementation and deployment >> > experience, and generalizing the design described in: >> > >> > o draft-omara-mls-architecture >> > o draft-barnes-mls-protocol >> > >> > Note that consensus is required both for changes to the current >> > protocol mechanisms and retention of current mechanisms. In >> > particular, because something is in the initial document set does >> > not imply that there is consensus around the feature or around >> > how it is specified. >> > >> > Milestones: >> > May 2018 - Initial working group documents for architecture and key >> management >> > Sept 2018 - Initial working group document adopted for message >> protection >> > Jan 2019 - Submit architecture document to IESG as Informational >> > Jun 2019 - Submit key management protocol to IESG as Proposed Standard >> > Sept 2019 - Submit message protection protocol to IESG as Proposed >> Standard >> > >> > Cheers, >> > >> > spt >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --089e0823f834413639056a214191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM.

On 18 April 2018 at 16:18, Richard Barnes <= rlb@ipv.sx> w= rote:
Hey Sean,

This looks good to me.=C2=A0 Ship it.

<= /div>
--Richard

On Fri, Apr 13, 2018 at 2:52 PM, S= ean Turner <sean@sn3rd.com> wrote:
Sorry I missed to minor edits fr= om Jonathan Lennox didn=E2=80=99t get copied over:

Messaging Layer Security (MLS) Charter (DRAFT)

Several Internet applications have a need for group key establishment
and message protection protocols with the following properties:

o Message Confidentiality - Messages can only be read
=C2=A0 by members of the group
o Message Integrity and Authentication - Each message
=C2=A0 has been sent by an authenticated sender, and has
=C2=A0 not been tampered with
o Membership Authentication - Each participant can verify
=C2=A0 the set of members in the group
o Asynchronicity - Keys can be established without any
=C2=A0 two participants being online at the same time
o Forward secrecy - Full compromise of a node at a point
=C2=A0 in time does not reveal past messages sent within the group
o Post-compromise security - Full compromise of a node at a
=C2=A0 point in time does not reveal future messages sent within the group<= br> o Scalability - Resource requirements have good scaling in the
=C2=A0 size of the group (preferably sub-linear)

Several widely-deployed applications have developed their own
protocols to meet these needs. While these protocols are similar,
no two are close enough to interoperate. As a result, each application
vendor has had to maintain their own protocol stack and independently
build trust in the quality of the protocol. The primary goal of this
working group is to develop a standard messaging security protocol
so that applications can share code, and so that there can be shared
validation of the protocol (as there has been with TLS 1.3).

It is not a goal of this group to enable interoperability / federation
between messaging applications beyond the key establishment,
authentication, and confidentiality services.=C2=A0 Full interoperability would require alignment at many different layers beyond security,
e.g., standard message transport and application semantics.=C2=A0 The
focus of this work is to develop a messaging security layer that
different applications can adapt to their own needs.

While authentication is a key goal of this working group, it is not
the objective of this working group to develop new authentication
technologies.=C2=A0 Rather, the security protocol developed by this
group will provide a way to leverage existing authentication
technologies to associate identities with keys used in the protocol,
just as TLS does with X.509.

In developing this protocol, we will draw on lessons learned from
several prior message-oriented security protocols, in addition to
the proprietary messaging security protocols deployed within
existing applications:

o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751<= br> o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc4880=
o Off the Record - =E2=80=8Bhttps://otr.cypherpunks= ..ca/Protocol-v3-4.1.1.html

o Signal - =E2=80=8Bhttps://signal.org/docs/

The intent of this working group is to follow the pattern of
TLS 1.3, with specification, implementation, and verification
proceeding in parallel.=C2=A0 By the time we arrive at RFC, we
hope to have several interoperable implementations as well
as a thorough security analysis.

The specifications developed by this working group will be
based on pre-standardization implementation and deployment
experience, generalizing the= design described in:

o draft-omara-mls-architecture
o draft-barnes-mls-protocol

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In
particular, because something is in the initial document set does
not imply that there is consensus around the feature or around
how it is specified.

Milestones:
May 2018 - Initial working group documents for architecture and key managem= ent
Sept 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational
Jun 2019 - Submit key management protocol to IESG as Proposed Standard
Sept 2019 - Submit message protection protocol to IESG as Proposed Standard=

Cheers,

spt

> On Apr 13, 2018, at 14:09, Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> The charter tweaks made since the BOF include tweaking (and reordering= ) some of the =E2=80=9Cproperty=E2=80=9D bullets:
> - added message confidentiality
> - message authentication changed to message integrity and authenticati= on
>
> I know that Ben Schwartz mentioned that we should look at our =E2=80= =9Cfull compromise=E2=80=9D definition, but in reviewing it the way it=E2= =80=99s used in FS and PCS property bullets it looks okay to me.=C2=A0 But,= maybe Ben can elaborate a bit.
>
> Anyway at this point, here=E2=80=99s what we=E2=80=99re working with:<= br> >
>
> Messaging Layer Security (MLS) Charter (DRAFT)
>
> Several Internet applications have a need for group key establishment<= br> > and message protection protocols with the following properties:
>
> o Message Confidentiality - Messages can only be read
>=C2=A0 =C2=A0by members of the group
> o Message Integrity and Authentication - Each message
>=C2=A0 =C2=A0has been sent by an authenticated sender, and has
>=C2=A0 =C2=A0not been tampered with
> o Membership Authentication - Each participant can verify
>=C2=A0 =C2=A0the set of members in the group
> o Asynchronicity - Keys can be established without any
>=C2=A0 =C2=A0two participants being online at the same time
> o Forward secrecy - Full compromise of a node at a point
>=C2=A0 =C2=A0in time does not reveal past messages sent within the grou= p
> o Post-compromise security - Full compromise of a node at a
>=C2=A0 =C2=A0point in time does not reveal future messages sent within = the group
> o Scalability - Resource requirements that have good scaling in the >=C2=A0 =C2=A0size of the group (preferably sub-linear)
>
> Several widely-deployed applications have developed their own
> protocols to meet these needs. While these protocols are similar,
> no two are close enough to interoperate. As a result, each application=
> vendor has had to maintain their own protocol stack and independently<= br> > build trust in the quality of the protocol. The primary goal of this > working group is to develop a standard messaging security protocol
> so that applications can share code, and so that there can be shared > validation of the protocol (as there has been with TLS 1.3).
>
> It is not a goal of this group to enable interoperability / federation=
> between messaging applications beyond the key establishment,
> authentication, and confidentiality services.=C2=A0 Full interoperabil= ity
> would require alignment at many different layers beyond security,
> e.g., standard message transport and application semantics.=C2=A0 The<= br> > focus of this work is to develop a messaging security layer that
> different applications can adapt to their own needs.
>
> While authentication is a key goal of this working group, it is not > the objective of this working group to develop new authentication
> technologies.=C2=A0 Rather, the security protocol developed by this > group will provide a way to leverage existing authentication
> technologies to associate identities with keys used in the protocol, > just as TLS does with X.509.
>
> In developing this protocol, we will draw on lessons learned from
> several prior message-oriented security protocols, in addition to
> the proprietary messaging security protocols deployed within
> existing applications:
>
> o S/MIME - =E2=80=8Bhttps://tools.ietf.org/html/rfc5751=
> o OpenPGP - =E2=80=8Bhttps://tools.ietf.org/html/rfc488= 0
> o Off the Record - =E2=80=8Bhttps://otr.cypher= punks.ca/Protocol-v3-4.1.1.html
> o Signal - =E2=80=8Bhttps://signal.org/docs/
>
> The intent of this working group is to follow the pattern of
> TLS 1.3, with specification, implementation, and verification
> proceeding in parallel.=C2=A0 By the time we arrive at RFC, we
> hope to have several interoperable implementations as well
> as a thorough security analysis.
>
> The specifications developed by this working group will be
> based on pre-standardization implementation and deployment
> experience, and generalizing the design described in:
>
> o draft-omara-mls-architecture
> o draft-barnes-mls-protocol
>
> Note that consensus is required both for changes to the current
> protocol mechanisms and retention of current mechanisms. In
> particular, because something is in the initial document set does
> not imply that there is consensus around the feature or around
> how it is specified.
>
> Milestones:
> May 2018 - Initial working group documents for architecture and key ma= nagement
> Sept 2018 - Initial working group document adopted for message protect= ion
> Jan 2019 - Submit architecture document to IESG as Informational
> Jun 2019 - Submit key management protocol to IESG as Proposed Standard=
> Sept 2019 - Submit message protection protocol to IESG as Proposed Sta= ndard
>
> Cheers,
>
> spt

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls


_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls


--089e0823f834413639056a214191-- From nobody Wed Apr 18 08:42:45 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38D31243F3 for ; Wed, 18 Apr 2018 08:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=xCPzjCkF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YGLnblhf 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 7G-4nsN5wLPV for ; Wed, 18 Apr 2018 08:42:41 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0851B120727 for ; Wed, 18 Apr 2018 08:42:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 487B921C3B for ; Wed, 18 Apr 2018 11:42:40 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Wed, 18 Apr 2018 11:42:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=cc:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject :x-me-sender:x-me-sender:x-sasl-enc; s=mesmtp; bh=+91HsuQDb+UQIO pNGSKf9hgDeIELH1zUEV3IG2LMQus=; b=xCPzjCkF+jgPaO+WZX8nqea1q7U9UV sfAgWDhhcNDoVdSvFlGC7vyFcVyT5fx7c506GGyGqFptxHV7MjGFthvhftO89hem PryIYTCgQHdfe8vIr+C/Ju7UUomnvOF7mMUosZfoZOsXpfB8mEaVNePzHRwXZ7v4 o2qfeAzEbz/s8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=+91HsuQDb +UQIOpNGSKf9hgDeIELH1zUEV3IG2LMQus=; b=YGLnblhf1XdLe6A/Q1ziu7CB5 FE4NSehdrgLSeGW3HKzVdx5ByK1Gj0r0d+YUTrlVykvqQZ8XTydL5aGZ3p39QNGk xrjeUUSPTzYEBtu0vPGLzHv/Rc02C/W5e0XIagfjmxHL1u5KUkxb0HrUEgayG0tD algveWqDXlKZ7cRDvww3CrTKe2q/hlnIo2OWJpPooY4suB7nUmn7crKX930yozW5 1C+YfvRSyql+ZbRnBfgAt370CtZEnGkjPClr/wfb0/dK/b5gPQHtboE8uKtK2uB/ wWHPYsQ6ZI01zlSMS+5W4KIgdK9fPMQyvTvZ2mb+lCJm+YJdmS3yJBqp6n0bQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0C57D9E382; Wed, 18 Apr 2018 11:42:39 -0400 (EDT) Message-Id: <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" Cc: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1524066159110122" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f3006b89 Date: Wed, 18 Apr 2018 16:42:39 +0100 References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> In-Reply-To: Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 15:42:44 -0000 This is a multi-part message in MIME format. --_----------=_1524066159110122 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" +1 On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote: > LGTM. >=20 > On 18 April 2018 at 16:18, Richard Barnes wrote: >> Hey Sean, >>=20 >> This looks good to me. Ship it. >>=20 >> --Richard >>=20 >> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner wrote:>>> = Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t get >>> copied over:>>> >>> Messaging Layer Security (MLS) Charter (DRAFT) >>> >>> Several Internet applications have a need for group key >>> establishment and message protection protocols with the following >>> properties: >>> >>> o Message Confidentiality - Messages can only be read by members >>> of the group o Message Integrity and Authentication - Each message >>> has been sent by an authenticated sender, and has not been >>> tampered with o Membership Authentication - Each participant can >>> verify the set of members in the group o Asynchronicity - Keys can >>> be established without any two participants being online at the >>> same time o Forward secrecy - Full compromise of a node at a point >>> in time does not reveal past messages sent within the group o Post- >>> compromise security - Full compromise of a node at a point in time >>> does not reveal future messages sent within the group o Scalability >>> - Resource requirements have good scaling in the>>> size of the grou= p (preferably sub-linear) >>>=20 >>> Several widely-deployed applications have developed their own >>> protocols to meet these needs. While these protocols are similar, >>> no two are close enough to interoperate. As a result, each >>> application>>> vendor has had to maintain their own protocol stack and >>> independently>>> build trust in the quality of the protocol. The prim= ary goal >>> of this>>> working group is to develop a standard messaging security = protocol>>> so that applications can share code, and so that there can be >>> shared>>> validation of the protocol (as there has been with TLS 1.3)= .=20 >>>=20 >>> It is not a goal of this group to enable interoperability / >>> federation>>> between messaging applications beyond the key establish= ment, >>> authentication, and confidentiality services. Full >>> interoperability>>> would require alignment at many different layers = beyond security, >>> e.g., standard message transport and application semantics. The >>> focus of this work is to develop a messaging security layer that >>> different applications can adapt to their own needs. >>>=20 >>> While authentication is a key goal of this working group, it is not>>>= the objective of this working group to develop new authentication >>> technologies. Rather, the security protocol developed by this >>> group will provide a way to leverage existing authentication >>> technologies to associate identities with keys used in the >>> protocol,>>> just as TLS does with X.509. >>>=20 >>> In developing this protocol, we will draw on lessons learned from >>> several prior message-oriented security protocols, in addition to >>> the proprietary messaging security protocols deployed within >>> existing applications: >>>=20 >>> o S/MIME - https://tools.ietf.org/html/rfc5751 >>> o OpenPGP - https://tools.ietf.org/html/rfc4880 >>> o Off the Record - >>> https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html[1]>>>=20 >>> o Signal - https://signal.org/docs/ >>>=20 >>> The intent of this working group is to follow the pattern of >>> TLS 1.3, with specification, implementation, and verification >>> proceeding in parallel. By the time we arrive at RFC, we >>> hope to have several interoperable implementations as well >>> as a thorough security analysis. >>>=20 >>> The specifications developed by this working group will be >>> based on pre-standardization implementation and deployment >>> experience, generalizing the design described in: >>> >>> o draft-omara-mls-architecture o draft-barnes-mls-protocol >>> >>> Note that consensus is required both for changes to the current >>> protocol mechanisms and retention of current mechanisms. In >>> particular, because something is in the initial document set does >>> not imply that there is consensus around the feature or around how >>> it is specified. >>> >>> Milestones: May 2018 - Initial working group documents for >>> architecture and key management Sept 2018 - Initial working group >>> document adopted for message protection Jan 2019 - Submit >>> architecture document to IESG as Informational Jun 2019 - Submit >>> key management protocol to IESG as Proposed Standard Sept 2019 - >>> Submit message protection protocol to IESG as Proposed Standard >>> >>> Cheers, >>> >>> spt >>>>>> > On Apr 13, 2018, at 14:09, Sean Turner wrote: >>> >=20 >>> > All, >>> >=20 >>> > The charter tweaks made since the BOF include tweaking (and >>> > reordering) some of the =E2=80=9Cproperty=E2=80=9D bullets:>>> > - = added message confidentiality >>> > - message authentication changed to message integrity and >>> > authentication>>> >=20 >>> > I know that Ben Schwartz mentioned that we should look at our >>> > =E2=80=9Cfull compromise=E2=80=9D definition, but in reviewing it th= e way it=E2=80=99s >>> > used in FS and PCS property bullets it looks okay to me. But, >>> > maybe Ben can elaborate a bit.>>> >=20 >>> > Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: >>> >=20 >>> >=20 >>> > Messaging Layer Security (MLS) Charter (DRAFT) >>> >=20 >>> > Several Internet applications have a need for group key >>> > establishment>>> > and message protection protocols with the follow= ing properties: >>> >=20 >>> > o Message Confidentiality - Messages can only be read >>> > by members of the group >>> > o Message Integrity and Authentication - Each message >>> > has been sent by an authenticated sender, and has >>> > not been tampered with >>> > o Membership Authentication - Each participant can verify >>> > the set of members in the group >>> > o Asynchronicity - Keys can be established without any >>> > two participants being online at the same time >>> > o Forward secrecy - Full compromise of a node at a point >>> > in time does not reveal past messages sent within the group >>> > o Post-compromise security - Full compromise of a node at a >>> > point in time does not reveal future messages sent within the >>> > group>>> > o Scalability - Resource requirements that have good s= caling in >>> > the>>> > size of the group (preferably sub-linear) >>> >=20 >>> > Several widely-deployed applications have developed their own >>> > protocols to meet these needs. While these protocols are similar,>>>= > no two are close enough to interoperate. As a result, each >>> > application>>> > vendor has had to maintain their own protocol stac= k and >>> > independently>>> > build trust in the quality of the protocol. The = primary goal of >>> > this>>> > working group is to develop a standard messaging security >>> > protocol>>> > so that applications can share code, and so that ther= e can be >>> > shared>>> > validation of the protocol (as there has been with TLS = 1.3).=20 >>> >=20 >>> > It is not a goal of this group to enable interoperability / >>> > federation>>> > between messaging applications beyond the key estab= lishment, >>> > authentication, and confidentiality services. Full >>> > interoperability>>> > would require alignment at many different lay= ers beyond security,>>> > e.g., standard message transport and application= semantics. The>>> > focus of this work is to develop a messaging securit= y layer that>>> > different applications can adapt to their own needs. >>> >=20 >>> > While authentication is a key goal of this working group, it is >>> > not>>> > the objective of this working group to develop new authent= ication>>> > technologies. Rather, the security protocol developed by this >>> > group will provide a way to leverage existing authentication >>> > technologies to associate identities with keys used in the >>> > protocol,>>> > just as TLS does with X.509. >>> >=20 >>> > In developing this protocol, we will draw on lessons learned from>>>= > several prior message-oriented security protocols, in addition to>>> >= the proprietary messaging security protocols deployed within >>> > existing applications: >>> >=20 >>> > o S/MIME - https://tools.ietf.org/html/rfc5751 >>> > o OpenPGP - https://tools.ietf.org/html/rfc4880 >>> > o Off the Record - >>> > https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html>>> > o Signal - h= ttps://signal.org/docs/ >>> >=20 >>> > The intent of this working group is to follow the pattern of >>> > TLS 1.3, with specification, implementation, and verification >>> > proceeding in parallel. By the time we arrive at RFC, we >>> > hope to have several interoperable implementations as well >>> > as a thorough security analysis. >>> >=20 >>> > The specifications developed by this working group will be >>> > based on pre-standardization implementation and deployment >>> > experience, and generalizing the design described in: >>> >=20 >>> > o draft-omara-mls-architecture >>> > o draft-barnes-mls-protocol >>> >=20 >>> > Note that consensus is required both for changes to the current >>> > protocol mechanisms and retention of current mechanisms. In >>> > particular, because something is in the initial document set does>>>= > not imply that there is consensus around the feature or around >>> > how it is specified. >>> >=20 >>> > Milestones: >>> > May 2018 - Initial working group documents for architecture and >>> > key management>>> > Sept 2018 - Initial working group document adop= ted for message >>> > protection>>> > Jan 2019 - Submit architecture document to IESG as = Informational>>> > Jun 2019 - Submit key management protocol to IESG as Pr= oposed >>> > Standard>>> > Sept 2019 - Submit message protection protocol to IES= G as >>> > Proposed Standard>>> >=20 >>> > Cheers, >>> >=20 >>> > spt >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >>=20 > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls Links: 1. https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html --_----------=_1524066159110122 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
+1


On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote:
LGTM.

On 18 April 2018 at 16:18, Richard Barnes <rlb@ipv.sx> wrote:
Hey Sean,

This looks good to me.  Ship it.

--Richard

On Fri, Apr 13, 2018 at 2:52 = PM, Sean Turner <sea= n@sn3rd.com> wrote:
Sorry I missed to minor e= dits from Jonathan Lennox didn=E2=80=99t get copied over:

Messaging Layer Secu= rity (MLS) Charter (DRAFT)

Several Internet applications have a ne= ed for group key establishment
and message protection protocols with th= e following properties:

o Message Confidentiality - Messages can o= nly be read
  by members of the group
o Message Integrity and = Authentication - Each message
  has been sent by an authenticated = sender, and has
  not been tampered with
o Membership Authenti= cation - Each participant can verify
  the set of members in the g= roup
o Asynchronicity - Keys can be established without any
  = two participants being online at the same time
o Forward secrecy - Full= compromise of a node at a point
  in time does not reveal past me= ssages sent within the group
o Post-compromise security - Full compromi= se of a node at a
  point in time does not reveal future messages = sent within the group
o Scalability - Resource requirements have= good scaling in the
  size = of the group (preferably sub-linear)

Several widely-deployed applica= tions have developed their own
protocols to meet these needs. = While these protocols are similar,
no two are close enough to inte= roperate. As a result, each application
vendor has had to maintain thei= r own protocol stack and independently
build trust in the quality of t= he protocol. The primary goal of this
working group is to develop a s= tandard messaging security protocol
so that applications can share = code, and so that there can be shared
validation of the protocol (as = there has been with TLS 1.3).

It is not a goal of this group = to enable interoperability / federation
between messaging applications = beyond the key establishment,
authentication, and confidentia= lity services.  Full interoperability
would require alignment at many= different layers beyond security,
e.g., standard message transpor= t and application semantics.  The
focus of this work is to develo= p a messaging security layer that
different applications can adap= t to their own needs.

While authentication is a key g= oal of this working group, it is not
the objective of this working g= roup to develop new authentication
technologies.  Rather, the= security protocol developed by this
group will provide a way to lev= erage existing authentication
technologies to associate ident= ities with keys used in the protocol,
just as TLS does with X.509.

In developing this protocol, we= will draw on lessons learned from
several prior message-oriented = security protocols, in addition to
the proprietary messaging secur= ity protocols deployed within
existing applications:



The intent of this working grou= p is to follow the pattern of
TLS 1.3, with specification, im= plementation, and verification
proceeding in parallel.  B= y the time we arrive at RFC, we
hope to have several interopera= ble implementations as well
as a thorough security analysis= .

The specifications developed by= this working group will be
based on pre-standardization im= plementation and deployment
experience, generalizi= ng the design described in:

o draft-omara-mls-ar= chitecture
o draft-barnes-mls-protocol

Note that consensus is = required both for changes to the current
protocol mechanisms and retent= ion of current mechanisms. In
particular, because something is in the i= nitial document set does
not imply that there is consensus around the f= eature or around
how it is specified.

Milestones:
May 2018= - Initial working group documents for architecture and key management
= Sept 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational
Jun= 2019 - Submit key management protocol to IESG as Proposed Standard
Sep= t 2019 - Submit message protection protocol to IESG as Proposed Standard
Cheers,

spt

> On Apr 13, 2018, = at 14:09, Sean Turner <sean@sn3rd.com<= /a>> wrote:
>
> All,
>
> The charter tweaks made si= nce the BOF include tweaking (and reordering) some of the =E2=80=9Cproperty= =E2=80=9D bullets:
> - added message confidenti= ality
> - message authentication c= hanged to message integrity and authentication
>
> I know that Ben Schwartz m= entioned that we should look at our =E2=80=9Cfull compromise=E2=80=9D defin= ition, but in reviewing it the way it=E2=80=99s used in FS and PCS property= bullets it looks okay to me.  But, maybe Ben can elaborate a bit.
=
>
> Anyway at this point, here= =E2=80=99s what we=E2=80=99re working with:
>
>
> Messaging Layer Security (= MLS) Charter (DRAFT)
>
> Several Internet applicati= ons have a need for group key establishment
> and message protection pro= tocols with the following properties:
>
> o Message Confidentiality = - Messages can only be read
>   by members of = the group
> o Message Integrity and Au= thentication - Each message
>   has been sent = by an authenticated sender, and has
>   not been tampe= red with
> o Membership Authenticatio= n - Each participant can verify
>   the set of mem= bers in the group
> o Asynchronicity - Keys ca= n be established without any
>   two participan= ts being online at the same time
> o Forward secrecy - Full c= ompromise of a node at a point
>   in time does n= ot reveal past messages sent within the group
> o Post-compromise security= - Full compromise of a node at a
>   point in time = does not reveal future messages sent within the group
> o Scalability - Resource r= equirements that have good scaling in the
>   size of the gr= oup (preferably sub-linear)
>
> Several widely-deployed ap= plications have developed their own
> protocols to meet these ne= eds. While these protocols are similar,
> no two are close enough to= interoperate. As a result, each application
> vendor has had to maintain= their own protocol stack and independently
> build trust in the quality= of the protocol. The primary goal of this
> working group is to develo= p a standard messaging security protocol
> so that applications can s= hare code, and so that there can be shared
> validation of the protocol= (as there has been with TLS 1.3).
>
> It is not a goal of this g= roup to enable interoperability / federation
> between messaging applicat= ions beyond the key establishment,
> authentication, and confid= entiality services.  Full interoperability
> would require alignment at= many different layers beyond security,
> e.g., standard message tra= nsport and application semantics.  The
> focus of this work is to d= evelop a messaging security layer that
> different applications can= adapt to their own needs.
>
> While authentication is a = key goal of this working group, it is not
> the objective of this work= ing group to develop new authentication
> technologies.  Rather= , the security protocol developed by this
> group will provide a way t= o leverage existing authentication
> technologies to associate = identities with keys used in the protocol,
> just as TLS does with X.50= 9.
>
> In developing this protoco= l, we will draw on lessons learned from
> several prior message-orie= nted security protocols, in addition to
> the proprietary messaging = security protocols deployed within
> existing applications:
=
>
>
> The intent of this working= group is to follow the pattern of
> TLS 1.3, with specificatio= n, implementation, and verification
> proceeding in parallel.&nb= sp; By the time we arrive at RFC, we
> hope to have several inter= operable implementations as well
> as a thorough security ana= lysis.
>
> The specifications develop= ed by this working group will be
> based on pre-standardizati= on implementation and deployment
> experience, and generalizi= ng the design described in:
>
> o draft-omara-mls-architec= ture
> o draft-barnes-mls-protoco= l
>
> Note that consensus is req= uired both for changes to the current
> protocol mechanisms and re= tention of current mechanisms. In
> particular, because someth= ing is in the initial document set does
> not imply that there is co= nsensus around the feature or around
> how it is specified.
>
> Milestones:
> May 2018 - Initial working= group documents for architecture and key management
> Sept 2018 - Initial workin= g group document adopted for message protection
> Jan 2019 - Submit architec= ture document to IESG as Informational
> Jun 2019 - Submit key mana= gement protocol to IESG as Proposed Standard
> Sept 2019 - Submit message= protection protocol to IESG as Proposed Standard
>
> Cheers,
>
> spt

______________________________<= wbr>_________________
MLS mailing list


_______________________________________________
MLS mailing list

_______________________________________________
MLS mailing list
--_----------=_1524066159110122-- From nobody Wed Apr 18 10:14:12 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34DD12D870 for ; Wed, 18 Apr 2018 10:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no 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 IY7FrixPo5NP for ; Wed, 18 Apr 2018 10:14:06 -0700 (PDT) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (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 3085012D777 for ; Wed, 18 Apr 2018 10:14:06 -0700 (PDT) Received: by mail-ua0-f181.google.com with SMTP id q26so1638192uab.0 for ; Wed, 18 Apr 2018 10:14:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dGdhzL8H3fltwMifOmI+j/JuJcQZAIPzxcrH6c/hqNs=; b=ixxzfUlInkkAYXpZPK91zxQEJg60xa767D512UhR/BlYkAj8rB1x+q1yoG7WSsktOQ Qb34KRvrzOluoGy6gUv5vxOJXjeJY3xTzsEEWNwBl2e6er2a5HrzeGi2oeGPLSXUCwzC p3PBn67lA2j/mAsyQvPHRI4JFOmcdPnLw/Gs21Oc1y4361iibN/AGnVJAqQSiBFrOcAT ZSssgLZ774xLaOsh5wsjdofy80zC4oxM45lO6g0QXT7Nle12cNNPpcH33Rna+ULNqVEp PtPnC7l9EIWVGYRQSf2Zz0pn3jxMqZ56dajEQXuhpVENpxUtYiwEmnQtFogoeBrVSSUv VNYg== X-Gm-Message-State: ALQs6tCsXlql0ioUuQZUOnel+ioLVvjDCpjXDALO8qvvZSwoXsBJCe+T BiGYt9l9e/GwLAaat5RrcXFt+WvwAhXW1PxYG90= X-Google-Smtp-Source: AIpwx49RmJBzcs2GT4ixP1r46+w6WDleNmU1oAPaw3x4ajcwJwc2E7ZEVuJYxtpVQ2LLQrT29XGXO6hISjd0pTwr0zM= X-Received: by 10.176.95.93 with SMTP id z29mr2147363uah.87.1524071645160; Wed, 18 Apr 2018 10:14:05 -0700 (PDT) MIME-Version: 1.0 References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com> In-Reply-To: <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com> From: Cas Cremers Date: Wed, 18 Apr 2018 17:13:54 +0000 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="f403045fe14c05ad46056a22959f" Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2018 17:14:10 -0000 --f403045fe14c05ad46056a22959f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, I am also happy with the revisions. Good to go! Cas On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, wrote: > +1 > > > On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote: > > LGTM. > > On 18 April 2018 at 16:18, Richard Barnes wrote: > > Hey Sean, > > This looks good to me. Ship it. > > --Richard > > On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner wrote: > > Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t get cop= ied over: > > Messaging Layer Security (MLS) Charter (DRAFT) > > Several Internet applications have a need for group key establishment > and message protection protocols with the following properties: > > o Message Confidentiality - Messages can only be read > by members of the group > o Message Integrity and Authentication - Each message > has been sent by an authenticated sender, and has > not been tampered with > o Membership Authentication - Each participant can verify > the set of members in the group > o Asynchronicity - Keys can be established without any > two participants being online at the same time > o Forward secrecy - Full compromise of a node at a point > in time does not reveal past messages sent within the group > o Post-compromise security - Full compromise of a node at a > point in time does not reveal future messages sent within the group > o Scalability - Resource requirements have good scaling in the > > size of the group (preferably sub-linear) > > Several widely-deployed applications have developed their own > protocols to meet these needs. While these protocols are similar, > no two are close enough to interoperate. As a result, each application > vendor has had to maintain their own protocol stack and independently > build trust in the quality of the protocol. The primary goal of this > working group is to develop a standard messaging security protocol > so that applications can share code, and so that there can be shared > validation of the protocol (as there has been with TLS 1.3). > > It is not a goal of this group to enable interoperability / federation > between messaging applications beyond the key establishment, > authentication, and confidentiality services. Full interoperability > would require alignment at many different layers beyond security, > e.g., standard message transport and application semantics. The > focus of this work is to develop a messaging security layer that > different applications can adapt to their own needs. > > While authentication is a key goal of this working group, it is not > the objective of this working group to develop new authentication > technologies. Rather, the security protocol developed by this > group will provide a way to leverage existing authentication > technologies to associate identities with keys used in the protocol, > just as TLS does with X.509. > > In developing this protocol, we will draw on lessons learned from > several prior message-oriented security protocols, in addition to > the proprietary messaging security protocols deployed within > existing applications: > > o S/MIME - https://tools.ietf.org/html/rfc5751 > o OpenPGP - https://tools.ietf.org/html/rfc4880 > o Off the Record - https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html > > > > o Signal - https://signal.org/docs/ > > The intent of this working group is to follow the pattern of > TLS 1.3, with specification, implementation, and verification > proceeding in parallel. By the time we arrive at RFC, we > hope to have several interoperable implementations as well > > as a thorough security analysis.. > > > The specifications developed by this working group will be > based on pre-standardization implementation and deployment > > experience, generalizing the design described in: > > o draft-omara-mls-architecture > o draft-barnes-mls-protocol > > Note that consensus is required both for changes to the current > protocol mechanisms and retention of current mechanisms. In > particular, because something is in the initial document set does > not imply that there is consensus around the feature or around > how it is specified. > > Milestones: > May 2018 - Initial working group documents for architecture and key > management > Sept 2018 - Initial working group document adopted for message protection > Jan 2019 - Submit architecture document to IESG as Informational > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > Sept 2019 - Submit message protection protocol to IESG as Proposed Standa= rd > > Cheers, > > spt > > > On Apr 13, 2018, at 14:09, Sean Turner wrote: > > > > All, > > > > The charter tweaks made since the BOF include tweaking (and reordering) > some of the =E2=80=9Cproperty=E2=80=9D bullets: > > - added message confidentiality > > - message authentication changed to message integrity and authenticatio= n > > > > I know that Ben Schwartz mentioned that we should look at our =E2=80=9C= full > compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99s = used in FS and PCS > property bullets it looks okay to me. But, maybe Ben can elaborate a bit= . > > > > Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: > > > > > > Messaging Layer Security (MLS) Charter (DRAFT) > > > > Several Internet applications have a need for group key establishment > > and message protection protocols with the following properties: > > > > o Message Confidentiality - Messages can only be read > > by members of the group > > o Message Integrity and Authentication - Each message > > has been sent by an authenticated sender, and has > > not been tampered with > > o Membership Authentication - Each participant can verify > > the set of members in the group > > o Asynchronicity - Keys can be established without any > > two participants being online at the same time > > o Forward secrecy - Full compromise of a node at a point > > in time does not reveal past messages sent within the group > > o Post-compromise security - Full compromise of a node at a > > point in time does not reveal future messages sent within the group > > o Scalability - Resource requirements that have good scaling in the > > size of the group (preferably sub-linear) > > > > Several widely-deployed applications have developed their own > > protocols to meet these needs. While these protocols are similar, > > no two are close enough to interoperate. As a result, each application > > vendor has had to maintain their own protocol stack and independently > > build trust in the quality of the protocol. The primary goal of this > > working group is to develop a standard messaging security protocol > > so that applications can share code, and so that there can be shared > > validation of the protocol (as there has been with TLS 1.3). > > > > It is not a goal of this group to enable interoperability / federation > > between messaging applications beyond the key establishment, > > authentication, and confidentiality services. Full interoperability > > would require alignment at many different layers beyond security, > > e.g., standard message transport and application semantics. The > > focus of this work is to develop a messaging security layer that > > different applications can adapt to their own needs. > > > > While authentication is a key goal of this working group, it is not > > the objective of this working group to develop new authentication > > technologies. Rather, the security protocol developed by this > > group will provide a way to leverage existing authentication > > technologies to associate identities with keys used in the protocol, > > just as TLS does with X.509. > > > > In developing this protocol, we will draw on lessons learned from > > several prior message-oriented security protocols, in addition to > > the proprietary messaging security protocols deployed within > > existing applications: > > > > o S/MIME - https://tools.ietf.org/html/rfc5751 > > o OpenPGP - https://tools.ietf.org/html/rfc4880 > > o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html > > o Signal - https://signal.org/docs/ > > > > The intent of this working group is to follow the pattern of > > TLS 1.3, with specification, implementation, and verification > > proceeding in parallel. By the time we arrive at RFC, we > > hope to have several interoperable implementations as well > > as a thorough security analysis. > > > > The specifications developed by this working group will be > > based on pre-standardization implementation and deployment > > experience, and generalizing the design described in: > > > > o draft-omara-mls-architecture > > o draft-barnes-mls-protocol > > > > Note that consensus is required both for changes to the current > > protocol mechanisms and retention of current mechanisms. In > > particular, because something is in the initial document set does > > not imply that there is consensus around the feature or around > > how it is specified. > > > > Milestones: > > May 2018 - Initial working group documents for architecture and key > management > > Sept 2018 - Initial working group document adopted for message protecti= on > > Jan 2019 - Submit architecture document to IESG as Informational > > Jun 2019 - Submit key management protocol to IESG as Proposed Standard > > Sept 2019 - Submit message protection protocol to IESG as Proposed > Standard > > > > Cheers, > > > > spt > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > *_______________________________________________* > MLS mailing list > MLS@ietf.org > > https://www.ietf..org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --f403045fe14c05ad46056a22959f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all,

I am also happy with the revisions. Good to go= !

Cas

On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <me@katriel.co.uk> wrote:
+1


On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote:
LGTM.

On 18 April 2018 at 16:18, Richa= rd Barnes <rlb@ipv.sx> wrote:
Hey Sean,

This looks good to me.=C2=A0 Ship it.

--Richard
=
On Fri,= Apr 13, 2018 at 2:52 PM, Sean Turner <sean@sn3rd.com> wrote:
Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t = get copied over:

Messaging Layer Securi= ty (MLS) Charter (DRAFT)

Several Internet applications have a need= for group key establishment
and message protection protocols with the = following properties:

o Message Confidentiality - Messages can onl= y be read
=C2=A0 by members of the group
o Message Integrity and Au= thentication - Each message
=C2=A0 has been sent by an authenticated se= nder, and has
=C2=A0 not been tampered with
o Membership Authentica= tion - Each participant can verify
=C2=A0 the set of members in the gro= up
o Asynchronicity - Keys can be established without any
=C2=A0 tw= o participants being online at the same time
o Forward secrecy - Full c= ompromise of a node at a point
=C2=A0 in time does not reveal past mess= ages sent within the group
o Post-compromise security - Full compromise= of a node at a
=C2=A0 point in time does not reveal future messages se= nt within the group
o Scalability - Resource requirements have g= ood scaling in the
<= blockquote type=3D"cite">
=C2=A0 size of the group (preferably sub-li= near)

Several widely-deployed applicati= ons have developed their own
protocols to meet these needs. Wh= ile these protocols are similar,
no two are close enough to intero= perate. As a result, each application
vendor has had to maintain their = own protocol stack and independently
build trust in the quality of the= protocol. The primary goal of this
working group is to develop a sta= ndard messaging security protocol
so that applications can share co= de, and so that there can be shared
validation of the protocol (as th= ere has been with TLS 1.3).

It is not a goal of this group to= enable interoperability / federation
between messaging applications be= yond the key establishment,
authentication, and confidentiali= ty services.=C2=A0 Full interoperability
would require alignment at many d= ifferent layers beyond security,
e.g., standard message transport = and application semantics.=C2=A0 The
focus of this work is to develop = a messaging security layer that
different applications can adapt = to their own needs.

While authentication is a key goa= l of this working group, it is not
the objective of this working gro= up to develop new authentication
technologies.=C2=A0 Rather, the s= ecurity protocol developed by this
group will provide a way to lever= age existing authentication
technologies to associate identit= ies with keys used in the protocol,
just as TLS does with X.509.
<= /div>

In developing this protocol, we w= ill draw on lessons learned from
several prior message-oriented se= curity protocols, in addition to
the proprietary messaging securit= y protocols deployed within
existing applications:

=


The intent of this working group = is to follow the pattern of
TLS 1.3, with specification, impl= ementation, and verification
proceeding in parallel.=C2=A0 By = the time we arrive at RFC, we
hope to have several interoperabl= e implementations as well
<= /blockquote>
=
as a thorough secu= rity analysis..
<= /blockquote>
<= div>

The specifications developed by t= his working group will be
based on pre-standardization impl= ementation and deployment
<= /blockquote>
experience, generalizing= the design described in:

o draft-omara-mls-arch= itecture
o draft-barnes-mls-protocol

Note that consensus is re= quired both for changes to the current
protocol mechanisms and retentio= n of current mechanisms. In
particular, because something is in the ini= tial document set does
not imply that there is consensus around the fea= ture or around
how it is specified.

Milestones:
May 2018 -= Initial working group documents for architecture and key management
Se= pt 2018 - Initial working group document adopted for message protection
= Jan 2019 - Submit architecture document to IESG as Informational
Jun 2= 019 - Submit key management protocol to IESG as Proposed Standard
Sept = 2019 - Submit message protection protocol to IESG as Proposed Standard
=
Cheers,

spt

> On Apr 13, 2018, at= 14:09, Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> The charter tweaks made sinc= e the BOF include tweaking (and reordering) some of the =E2=80=9Cproperty= =E2=80=9D bullets:
> - added message confidential= ity
> - message authentication cha= nged to message integrity and authentication
>
> I know that Ben Schwartz men= tioned that we should look at our =E2=80=9Cfull compromise=E2=80=9D definit= ion, but in reviewing it the way it=E2=80=99s used in FS and PCS property b= ullets it looks okay to me.=C2=A0 But, maybe Ben can elaborate a bit.
>
> Anyway at this point, here= =E2=80=99s what we=E2=80=99re working with:
>
>
> Messaging Layer Security (ML= S) Charter (DRAFT)
>
> Several Internet application= s have a need for group key establishment
> and message protection proto= cols with the following properties:
>
> o Message Confidentiality - = Messages can only be read
>=C2=A0 =C2=A0by members of th= e group
> o Message Integrity and Auth= entication - Each message
>=C2=A0 =C2=A0has been sent by= an authenticated sender, and has
>=C2=A0 =C2=A0not been tampere= d with
> o Membership Authentication = - Each participant can verify
>=C2=A0 =C2=A0the set of membe= rs in the group
> o Asynchronicity - Keys can = be established without any
>=C2=A0 =C2=A0two participants= being online at the same time
> o Forward secrecy - Full com= promise of a node at a point
>=C2=A0 =C2=A0in time does not= reveal past messages sent within the group
> o Post-compromise security -= Full compromise of a node at a
>=C2=A0 =C2=A0point in time do= es not reveal future messages sent within the group
> o Scalability - Resource req= uirements that have good scaling in the
>=C2=A0 =C2=A0size of the grou= p (preferably sub-linear)
>
> Several widely-deployed appl= ications have developed their own
> protocols to meet these need= s. While these protocols are similar,
> no two are close enough to i= nteroperate. As a result, each application
> vendor has had to maintain t= heir own protocol stack and independently
> build trust in the quality o= f the protocol. The primary goal of this
> working group is to develop = a standard messaging security protocol
> so that applications can sha= re code, and so that there can be shared
> validation of the protocol (= as there has been with TLS 1.3).
>
> It is not a goal of this gro= up to enable interoperability / federation
> between messaging applicatio= ns beyond the key establishment,
> authentication, and confiden= tiality services.=C2=A0 Full interoperability
> would require alignment at m= any different layers beyond security,
> e.g., standard message trans= port and application semantics.=C2=A0 The
> focus of this work is to dev= elop a messaging security layer that
> different applications can a= dapt to their own needs.
>
> While authentication is a ke= y goal of this working group, it is not
> the objective of this workin= g group to develop new authentication
> technologies.=C2=A0 Rather, = the security protocol developed by this
> group will provide a way to = leverage existing authentication
> technologies to associate id= entities with keys used in the protocol,
> just as TLS does with X.509.=
>
> In developing this protocol,= we will draw on lessons learned from
> several prior message-orient= ed security protocols, in addition to
> the proprietary messaging se= curity protocols deployed within
> existing applications:
>
> o Signal - https://signal.org/docs/
>
> The intent of this working g= roup is to follow the pattern of
> TLS 1.3, with specification,= implementation, and verification
> proceeding in parallel.=C2= =A0 By the time we arrive at RFC, we
> hope to have several interop= erable implementations as well
> as a thorough security analy= sis.
>
> The specifications developed= by this working group will be
> based on pre-standardization= implementation and deployment
> experience, and generalizing= the design described in:
>
> o draft-omara-mls-architectu= re
> o draft-barnes-mls-protocol<= br>
>
> Note that consensus is requi= red both for changes to the current
> protocol mechanisms and rete= ntion of current mechanisms. In
> particular, because somethin= g is in the initial document set does
> not imply that there is cons= ensus around the feature or around
> how it is specified.
>
> Milestones:
> May 2018 - Initial working g= roup documents for architecture and key management
> Sept 2018 - Initial working = group document adopted for message protection
> Jan 2019 - Submit architectu= re document to IESG as Informational
> Jun 2019 - Submit key manage= ment protocol to IESG as Proposed Standard
> Sept 2019 - Submit message p= rotection protocol to IESG as Proposed Standard
>
> Cheers,
>
> spt

_________________________________= ______________
MLS mailing list
<= blockquote type=3D"cite">

__________________________________= _____________
MLS mailing list

_______________________________________________
MLS mailing list
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--f403045fe14c05ad46056a22959f-- From nobody Wed Apr 18 22:33:31 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042B3129C6B for ; Wed, 18 Apr 2018 22:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=jXV45G+M; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kBwCW7hG 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 ViNIsWyzMdTj for ; Wed, 18 Apr 2018 22:33:24 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 24773128961 for ; Wed, 18 Apr 2018 22:33:24 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w3J5TRI8012881; Wed, 18 Apr 2018 22:33:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=88sxQCf1uHPLbt0m5akfya/SkznBVsbeHE8BFbGFJ/Q=; b=jXV45G+Mm7ogyDJnbEXTepkdNkwVuMs+vgODicusi6nsRhXu/Tx9yB628vmIOJO/ZkIW 39eKRzqWLkxVBf20kmZ83z3YKq0Lvnr+/4IrCLiZuF012u5hSsmcv1HY7BypJg6SJKXn Zdxixji7vjWp5KsHRWfghwykrhdHVjv9lt8= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2hej26r8qm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2018 22:33:19 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 19 Apr 2018 01:33:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=88sxQCf1uHPLbt0m5akfya/SkznBVsbeHE8BFbGFJ/Q=; b=kBwCW7hGQsO64ysP0f4qHKUvMe+nuvbbWY6EgQDhJbt8fVy4Nv9uOakcpyyLEGcilvspXd1ElXdTIMbdMLANf6iBFma4ZQmo9plo0CDku3Yo8PpGfy3023hdMlp1B6cN/77u1k7ZyowpPsypJ69xXFFANC+gJLSWcvj5h3u/SaI= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1302.namprd15.prod.outlook.com (10.172.181.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.675.14; Thu, 19 Apr 2018 05:33:17 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0675.015; Thu, 19 Apr 2018 05:33:17 +0000 From: Jon Millican To: Cas Cremers CC: Katriel Cohn-Gordon , "mls@ietf.org" Thread-Topic: [MLS] Revised MLS charter Thread-Index: AQHT01KkyGNH+qJv5kS52HzR1WuZAKP/CoAAgAef34CAAAW+AIAAAQCAgAAZfwCAAM6UeQ== Date: Thu, 19 Apr 2018 05:33:16 +0000 Message-ID: References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.ox.ac.uk; dkim=none (message not signed) header.d=none;cs.ox.ac.uk; dmarc=none action=none header.from=fb.com; x-originating-ip: [82.39.102.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1302; 7:718hP3J05Ja10FQv9xHsTE63jn3/OFQHGNwHuScjVcGhvYxw8c5n4JiQxozwkqIe7Hj+2a1X+K7DY5BPUbeO3FSWA94OzpbrmTRNG/mroiipHHO0gb+hY6FpHplnr2xlliBPdN+eo48Ropg2zLgzwc7L26mIrAnpxYsFP/lUrUriuvTVAbXHMu5KRlpv3yO1sEDj4nUuT55fgI2kci4EUmqbyrRDqRRMQ6QB4P8zegnf/cEcImGOF3jyK1XSSC8j; 20:XP6Eu9kWFwXiFXypBFcM5xl7ijWe7YnKHSTfyYA3s73GLBSHVstORf9PLoYGHWwVH8bX6SqDccNFalVj/RiDFvfZJrJW7cqIK57CJDB3XX62Didp3zo/1JPT+hUj0ZScHUj7F5dbXZQgQ5oxaQc5UflzY7PuXJ+m+M2pS5ZL8Nc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1302; x-ms-traffictypediagnostic: CY4PR15MB1302: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(209352067349851)(192374486261705)(100405760836317)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231232)(11241501184)(944501327)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR15MB1302; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1302; x-forefront-prvs: 0647963F84 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(39860400002)(39380400002)(6486002)(81166006)(2900100001)(8936002)(6916009)(476003)(606006)(8676002)(66066001)(229853002)(5660300001)(11346002)(2616005)(102836004)(7736002)(26005)(6436002)(83716003)(86362001)(446003)(36756003)(5250100002)(575784001)(3846002)(478600001)(186003)(6506007)(3280700002)(53546011)(82746002)(6246003)(99286004)(6116002)(2906002)(14454004)(4326008)(3660700001)(53936002)(55236004)(76176011)(59450400001)(9886003)(54896002)(6306002)(316002)(93886005)(33656002)(966005)(6512007)(236005)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1302; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; MLV:sfv; x-microsoft-antispam-message-info: silTGsnm2iPSuSY0zpaXycgFCgvax7vMv4Wp4s6OwVqctGd3SkaJr4I1p/k3gNJ4EBAsIM0vhZLlR8T60iI3GakwOp1pz4fWk8tewiyg6zr5/kHDMNwUEnzZySjj7tAxaHwWGfs/FCwZsSNxcSg5CSDfb8lXqXe4JDvOuRRSXNhO1/a++1J/H1hUcoAJDcAT spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EBC0A703D3454DD3B859C0BD1FD7660Afbcom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 119c5887-03cf-4767-b2f1-08d5a5b70db1 X-MS-Exchange-CrossTenant-Network-Message-Id: 119c5887-03cf-4767-b2f1-08d5a5b70db1 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2018 05:33:16.8890 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1302 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-04-19_02:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 05:33:29 -0000 --_000_EBC0A703D3454DD3B859C0BD1FD7660Afbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXdlc29tZSwgbG9va3MgZ29vZCB0byBtZS4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpPbiAx OCBBcHIgMjAxOCwgYXQgMTg6MTUsIENhcyBDcmVtZXJzIDxjYXMuY3JlbWVyc0Bjcy5veC5hYy51 azxtYWlsdG86Y2FzLmNyZW1lcnNAY3Mub3guYWMudWs+PiB3cm90ZToNCg0KRGVhciBhbGwsDQoN CkkgYW0gYWxzbyBoYXBweSB3aXRoIHRoZSByZXZpc2lvbnMuIEdvb2QgdG8gZ28hDQoNCkNhcw0K DQpPbiBXZWQsIDE4IEFwciAyMDE4LCAxNjo0MiBLYXRyaWVsIENvaG4tR29yZG9uLCA8bWVAa2F0 cmllbC5jby51azxtYWlsdG86bWVAa2F0cmllbC5jby51az4+IHdyb3RlOg0KKzENCg0KDQpPbiBX ZWQsIDE4IEFwciAyMDE4LCBhdCA0OjM5IFBNLCBEYXZlIENyaWRsYW5kIHdyb3RlOg0KTEdUTS4N Cg0KT24gMTggQXByaWwgMjAxOCBhdCAxNjoxOCwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8 bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkhleSBTZWFuLA0KDQpUaGlzIGxvb2tzIGdvb2Qg dG8gbWUuICBTaGlwIGl0Lg0KDQotLVJpY2hhcmQNCk9uIEZyaSwgQXByIDEzLCAyMDE4IGF0IDI6 NTIgUE0sIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbTxtYWlsdG86c2VhbkBzbjNyZC5jb20+ PiB3cm90ZToNClNvcnJ5IEkgbWlzc2VkIHRvIG1pbm9yIGVkaXRzIGZyb20gSm9uYXRoYW4gTGVu bm94IGRpZG7igJl0IGdldCBjb3BpZWQgb3ZlcjoNCg0KTWVzc2FnaW5nIExheWVyIFNlY3VyaXR5 IChNTFMpIENoYXJ0ZXIgKERSQUZUKQ0KDQpTZXZlcmFsIEludGVybmV0IGFwcGxpY2F0aW9ucyBo YXZlIGEgbmVlZCBmb3IgZ3JvdXAga2V5IGVzdGFibGlzaG1lbnQNCmFuZCBtZXNzYWdlIHByb3Rl Y3Rpb24gcHJvdG9jb2xzIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOg0KDQpvIE1lc3Nh Z2UgQ29uZmlkZW50aWFsaXR5IC0gTWVzc2FnZXMgY2FuIG9ubHkgYmUgcmVhZA0KICBieSBtZW1i ZXJzIG9mIHRoZSBncm91cA0KbyBNZXNzYWdlIEludGVncml0eSBhbmQgQXV0aGVudGljYXRpb24g LSBFYWNoIG1lc3NhZ2UNCiAgaGFzIGJlZW4gc2VudCBieSBhbiBhdXRoZW50aWNhdGVkIHNlbmRl ciwgYW5kIGhhcw0KICBub3QgYmVlbiB0YW1wZXJlZCB3aXRoDQpvIE1lbWJlcnNoaXAgQXV0aGVu dGljYXRpb24gLSBFYWNoIHBhcnRpY2lwYW50IGNhbiB2ZXJpZnkNCiAgdGhlIHNldCBvZiBtZW1i ZXJzIGluIHRoZSBncm91cA0KbyBBc3luY2hyb25pY2l0eSAtIEtleXMgY2FuIGJlIGVzdGFibGlz aGVkIHdpdGhvdXQgYW55DQogIHR3byBwYXJ0aWNpcGFudHMgYmVpbmcgb25saW5lIGF0IHRoZSBz YW1lIHRpbWUNCm8gRm9yd2FyZCBzZWNyZWN5IC0gRnVsbCBjb21wcm9taXNlIG9mIGEgbm9kZSBh dCBhIHBvaW50DQogIGluIHRpbWUgZG9lcyBub3QgcmV2ZWFsIHBhc3QgbWVzc2FnZXMgc2VudCB3 aXRoaW4gdGhlIGdyb3VwDQpvIFBvc3QtY29tcHJvbWlzZSBzZWN1cml0eSAtIEZ1bGwgY29tcHJv bWlzZSBvZiBhIG5vZGUgYXQgYQ0KICBwb2ludCBpbiB0aW1lIGRvZXMgbm90IHJldmVhbCBmdXR1 cmUgbWVzc2FnZXMgc2VudCB3aXRoaW4gdGhlIGdyb3VwDQpvIFNjYWxhYmlsaXR5IC0gUmVzb3Vy Y2UgcmVxdWlyZW1lbnRzIGhhdmUgZ29vZCBzY2FsaW5nIGluIHRoZQ0KICBzaXplIG9mIHRoZSBn cm91cCAocHJlZmVyYWJseSBzdWItbGluZWFyKQ0KDQpTZXZlcmFsIHdpZGVseS1kZXBsb3llZCBh cHBsaWNhdGlvbnMgaGF2ZSBkZXZlbG9wZWQgdGhlaXIgb3duDQpwcm90b2NvbHMgdG8gbWVldCB0 aGVzZSBuZWVkcy4gV2hpbGUgdGhlc2UgcHJvdG9jb2xzIGFyZSBzaW1pbGFyLA0Kbm8gdHdvIGFy ZSBjbG9zZSBlbm91Z2ggdG8gaW50ZXJvcGVyYXRlLiBBcyBhIHJlc3VsdCwgZWFjaCBhcHBsaWNh dGlvbg0KdmVuZG9yIGhhcyBoYWQgdG8gbWFpbnRhaW4gdGhlaXIgb3duIHByb3RvY29sIHN0YWNr IGFuZCBpbmRlcGVuZGVudGx5DQpidWlsZCB0cnVzdCBpbiB0aGUgcXVhbGl0eSBvZiB0aGUgcHJv dG9jb2wuIFRoZSBwcmltYXJ5IGdvYWwgb2YgdGhpcw0Kd29ya2luZyBncm91cCBpcyB0byBkZXZl bG9wIGEgc3RhbmRhcmQgbWVzc2FnaW5nIHNlY3VyaXR5IHByb3RvY29sDQpzbyB0aGF0IGFwcGxp Y2F0aW9ucyBjYW4gc2hhcmUgY29kZSwgYW5kIHNvIHRoYXQgdGhlcmUgY2FuIGJlIHNoYXJlZA0K dmFsaWRhdGlvbiBvZiB0aGUgcHJvdG9jb2wgKGFzIHRoZXJlIGhhcyBiZWVuIHdpdGggVExTIDEu MykuDQoNCkl0IGlzIG5vdCBhIGdvYWwgb2YgdGhpcyBncm91cCB0byBlbmFibGUgaW50ZXJvcGVy YWJpbGl0eSAvIGZlZGVyYXRpb24NCmJldHdlZW4gbWVzc2FnaW5nIGFwcGxpY2F0aW9ucyBiZXlv bmQgdGhlIGtleSBlc3RhYmxpc2htZW50LA0KYXV0aGVudGljYXRpb24sIGFuZCBjb25maWRlbnRp YWxpdHkgc2VydmljZXMuICBGdWxsIGludGVyb3BlcmFiaWxpdHkNCndvdWxkIHJlcXVpcmUgYWxp Z25tZW50IGF0IG1hbnkgZGlmZmVyZW50IGxheWVycyBiZXlvbmQgc2VjdXJpdHksDQplLmcuLCBz dGFuZGFyZCBtZXNzYWdlIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gc2VtYW50aWNzLiAgVGhl DQpmb2N1cyBvZiB0aGlzIHdvcmsgaXMgdG8gZGV2ZWxvcCBhIG1lc3NhZ2luZyBzZWN1cml0eSBs YXllciB0aGF0DQpkaWZmZXJlbnQgYXBwbGljYXRpb25zIGNhbiBhZGFwdCB0byB0aGVpciBvd24g bmVlZHMuDQoNCldoaWxlIGF1dGhlbnRpY2F0aW9uIGlzIGEga2V5IGdvYWwgb2YgdGhpcyB3b3Jr aW5nIGdyb3VwLCBpdCBpcyBub3QNCnRoZSBvYmplY3RpdmUgb2YgdGhpcyB3b3JraW5nIGdyb3Vw IHRvIGRldmVsb3AgbmV3IGF1dGhlbnRpY2F0aW9uDQp0ZWNobm9sb2dpZXMuICBSYXRoZXIsIHRo ZSBzZWN1cml0eSBwcm90b2NvbCBkZXZlbG9wZWQgYnkgdGhpcw0KZ3JvdXAgd2lsbCBwcm92aWRl IGEgd2F5IHRvIGxldmVyYWdlIGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uDQp0ZWNobm9sb2dpZXMg dG8gYXNzb2NpYXRlIGlkZW50aXRpZXMgd2l0aCBrZXlzIHVzZWQgaW4gdGhlIHByb3RvY29sLA0K anVzdCBhcyBUTFMgZG9lcyB3aXRoIFguNTA5Lg0KDQpJbiBkZXZlbG9waW5nIHRoaXMgcHJvdG9j b2wsIHdlIHdpbGwgZHJhdyBvbiBsZXNzb25zIGxlYXJuZWQgZnJvbQ0Kc2V2ZXJhbCBwcmlvciBt ZXNzYWdlLW9yaWVudGVkIHNlY3VyaXR5IHByb3RvY29scywgaW4gYWRkaXRpb24gdG8NCnRoZSBw cm9wcmlldGFyeSBtZXNzYWdpbmcgc2VjdXJpdHkgcHJvdG9jb2xzIGRlcGxveWVkIHdpdGhpbg0K ZXhpc3RpbmcgYXBwbGljYXRpb25zOg0KDQpvIFMvTUlNRSAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM1NzUxPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1NzUxJmQ9RHdNRmFRJmM9NVZEMFJU dE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT12THc3eVI4X0JIRVRI T20zZmNaZWplQXIzYUJacHZnM0hMOEc1VC1zbTdVJnM9YllwekloaTUtOHgycTg5SkowbE1pWnZy cW04cFpQdDYtYkwxLTA1TkJiWSZlPT4NCm8gT3BlblBHUCAtIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM0ODgwPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM0ODgwJmQ9RHdNRmFRJmM9NVZEMFJU dE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT12THc3eVI4X0JIRVRI T20zZmNaZWplQXIzYUJacHZnM0hMOEc1VC1zbTdVJnM9eUVsUUt2SjVOdnFYc3hEcl9MSXJJZFBJ dmxQV050TEhaWi1fRTlyeEtURSZlPT4NCm8gT2ZmIHRoZSBSZWNvcmQgLSBodHRwczovL290ci5j eXBoZXJwdW5rcy4uLmNhL1Byb3RvY29sLXYzLTQuMS4xLmh0bWw8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19vdHIuY3lwaGVycHVua3MuY2FfUHJv dG9jb2wtMkR2My0yRDQuMS4xLmh0bWwmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3 JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXZMdzd5UjhfQkhFVEhPbTNmY1plamVBcjNhQlpw dmczSEw4RzVULXNtN1Umcz1xR3lYczJhLWRnY0FZaENkLUdXZE5LRFk4WVF0amkzYTdCMFJ2RldH UWdNJmU9Pg0KDQpvIFNpZ25hbCAtIGh0dHBzOi8vc2lnbmFsLm9yZy9kb2NzLzxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3NpZ25hbC5vcmdfZG9j c18mZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFN YTg0USZtPXZMdzd5UjhfQkhFVEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1Umcz0tbDVC Zk1CU2dpNWVod2d5SjVlVklHc3BEUjA0M1pFWGlFNTRDeWJFQUFVJmU9Pg0KDQpUaGUgaW50ZW50 IG9mIHRoaXMgd29ya2luZyBncm91cCBpcyB0byBmb2xsb3cgdGhlIHBhdHRlcm4gb2YNClRMUyAx LjMsIHdpdGggc3BlY2lmaWNhdGlvbiwgaW1wbGVtZW50YXRpb24sIGFuZCB2ZXJpZmljYXRpb24N CnByb2NlZWRpbmcgaW4gcGFyYWxsZWwuICBCeSB0aGUgdGltZSB3ZSBhcnJpdmUgYXQgUkZDLCB3 ZQ0KaG9wZSB0byBoYXZlIHNldmVyYWwgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgYXMg d2VsbA0KYXMgYSB0aG9yb3VnaCBzZWN1cml0eSBhbmFseXNpcy4uDQoNClRoZSBzcGVjaWZpY2F0 aW9ucyBkZXZlbG9wZWQgYnkgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgYmUNCmJhc2VkIG9uIHBy ZS1zdGFuZGFyZGl6YXRpb24gaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQNCmV4cGVyaWVu Y2UsIGdlbmVyYWxpemluZyB0aGUgZGVzaWduIGRlc2NyaWJlZCBpbjoNCg0KbyBkcmFmdC1vbWFy YS1tbHMtYXJjaGl0ZWN0dXJlDQpvIGRyYWZ0LWJhcm5lcy1tbHMtcHJvdG9jb2wNCg0KTm90ZSB0 aGF0IGNvbnNlbnN1cyBpcyByZXF1aXJlZCBib3RoIGZvciBjaGFuZ2VzIHRvIHRoZSBjdXJyZW50 DQpwcm90b2NvbCBtZWNoYW5pc21zIGFuZCByZXRlbnRpb24gb2YgY3VycmVudCBtZWNoYW5pc21z LiBJbg0KcGFydGljdWxhciwgYmVjYXVzZSBzb21ldGhpbmcgaXMgaW4gdGhlIGluaXRpYWwgZG9j dW1lbnQgc2V0IGRvZXMNCm5vdCBpbXBseSB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1cyBhcm91bmQg dGhlIGZlYXR1cmUgb3IgYXJvdW5kDQpob3cgaXQgaXMgc3BlY2lmaWVkLg0KDQpNaWxlc3RvbmVz Og0KTWF5IDIwMTggLSBJbml0aWFsIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIGZvciBhcmNoaXRl Y3R1cmUgYW5kIGtleSBtYW5hZ2VtZW50DQpTZXB0IDIwMTggLSBJbml0aWFsIHdvcmtpbmcgZ3Jv dXAgZG9jdW1lbnQgYWRvcHRlZCBmb3IgbWVzc2FnZSBwcm90ZWN0aW9uDQpKYW4gMjAxOSAtIFN1 Ym1pdCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsDQpKdW4g MjAxOSAtIFN1Ym1pdCBrZXkgbWFuYWdlbWVudCBwcm90b2NvbCB0byBJRVNHIGFzIFByb3Bvc2Vk IFN0YW5kYXJkDQpTZXB0IDIwMTkgLSBTdWJtaXQgbWVzc2FnZSBwcm90ZWN0aW9uIHByb3RvY29s IHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQNCg0KQ2hlZXJzLA0KDQpzcHQNCg0KPiBPbiBB cHIgMTMsIDIwMTgsIGF0IDE0OjA5LCBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb208bWFpbHRv OnNlYW5Ac24zcmQuY29tPj4gd3JvdGU6DQo+DQo+IEFsbCwNCj4NCj4gVGhlIGNoYXJ0ZXIgdHdl YWtzIG1hZGUgc2luY2UgdGhlIEJPRiBpbmNsdWRlIHR3ZWFraW5nIChhbmQgcmVvcmRlcmluZykg c29tZSBvZiB0aGUg4oCccHJvcGVydHnigJ0gYnVsbGV0czoNCj4gLSBhZGRlZCBtZXNzYWdlIGNv bmZpZGVudGlhbGl0eQ0KPiAtIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gY2hhbmdlZCB0byBtZXNz YWdlIGludGVncml0eSBhbmQgYXV0aGVudGljYXRpb24NCj4NCj4gSSBrbm93IHRoYXQgQmVuIFNj aHdhcnR6IG1lbnRpb25lZCB0aGF0IHdlIHNob3VsZCBsb29rIGF0IG91ciDigJxmdWxsIGNvbXBy b21pc2XigJ0gZGVmaW5pdGlvbiwgYnV0IGluIHJldmlld2luZyBpdCB0aGUgd2F5IGl04oCZcyB1 c2VkIGluIEZTIGFuZCBQQ1MgcHJvcGVydHkgYnVsbGV0cyBpdCBsb29rcyBva2F5IHRvIG1lLiAg QnV0LCBtYXliZSBCZW4gY2FuIGVsYWJvcmF0ZSBhIGJpdC4NCj4NCj4gQW55d2F5IGF0IHRoaXMg cG9pbnQsIGhlcmXigJlzIHdoYXQgd2XigJlyZSB3b3JraW5nIHdpdGg6DQo+DQo+DQo+IE1lc3Nh Z2luZyBMYXllciBTZWN1cml0eSAoTUxTKSBDaGFydGVyIChEUkFGVCkNCj4NCj4gU2V2ZXJhbCBJ bnRlcm5ldCBhcHBsaWNhdGlvbnMgaGF2ZSBhIG5lZWQgZm9yIGdyb3VwIGtleSBlc3RhYmxpc2ht ZW50DQo+IGFuZCBtZXNzYWdlIHByb3RlY3Rpb24gcHJvdG9jb2xzIHdpdGggdGhlIGZvbGxvd2lu ZyBwcm9wZXJ0aWVzOg0KPg0KPiBvIE1lc3NhZ2UgQ29uZmlkZW50aWFsaXR5IC0gTWVzc2FnZXMg Y2FuIG9ubHkgYmUgcmVhZA0KPiAgIGJ5IG1lbWJlcnMgb2YgdGhlIGdyb3VwDQo+IG8gTWVzc2Fn ZSBJbnRlZ3JpdHkgYW5kIEF1dGhlbnRpY2F0aW9uIC0gRWFjaCBtZXNzYWdlDQo+ICAgaGFzIGJl ZW4gc2VudCBieSBhbiBhdXRoZW50aWNhdGVkIHNlbmRlciwgYW5kIGhhcw0KPiAgIG5vdCBiZWVu IHRhbXBlcmVkIHdpdGgNCj4gbyBNZW1iZXJzaGlwIEF1dGhlbnRpY2F0aW9uIC0gRWFjaCBwYXJ0 aWNpcGFudCBjYW4gdmVyaWZ5DQo+ICAgdGhlIHNldCBvZiBtZW1iZXJzIGluIHRoZSBncm91cA0K PiBvIEFzeW5jaHJvbmljaXR5IC0gS2V5cyBjYW4gYmUgZXN0YWJsaXNoZWQgd2l0aG91dCBhbnkN Cj4gICB0d28gcGFydGljaXBhbnRzIGJlaW5nIG9ubGluZSBhdCB0aGUgc2FtZSB0aW1lDQo+IG8g Rm9yd2FyZCBzZWNyZWN5IC0gRnVsbCBjb21wcm9taXNlIG9mIGEgbm9kZSBhdCBhIHBvaW50DQo+ ICAgaW4gdGltZSBkb2VzIG5vdCByZXZlYWwgcGFzdCBtZXNzYWdlcyBzZW50IHdpdGhpbiB0aGUg Z3JvdXANCj4gbyBQb3N0LWNvbXByb21pc2Ugc2VjdXJpdHkgLSBGdWxsIGNvbXByb21pc2Ugb2Yg YSBub2RlIGF0IGENCj4gICBwb2ludCBpbiB0aW1lIGRvZXMgbm90IHJldmVhbCBmdXR1cmUgbWVz c2FnZXMgc2VudCB3aXRoaW4gdGhlIGdyb3VwDQo+IG8gU2NhbGFiaWxpdHkgLSBSZXNvdXJjZSBy ZXF1aXJlbWVudHMgdGhhdCBoYXZlIGdvb2Qgc2NhbGluZyBpbiB0aGUNCj4gICBzaXplIG9mIHRo ZSBncm91cCAocHJlZmVyYWJseSBzdWItbGluZWFyKQ0KPg0KPiBTZXZlcmFsIHdpZGVseS1kZXBs b3llZCBhcHBsaWNhdGlvbnMgaGF2ZSBkZXZlbG9wZWQgdGhlaXIgb3duDQo+IHByb3RvY29scyB0 byBtZWV0IHRoZXNlIG5lZWRzLiBXaGlsZSB0aGVzZSBwcm90b2NvbHMgYXJlIHNpbWlsYXIsDQo+ IG5vIHR3byBhcmUgY2xvc2UgZW5vdWdoIHRvIGludGVyb3BlcmF0ZS4gQXMgYSByZXN1bHQsIGVh Y2ggYXBwbGljYXRpb24NCj4gdmVuZG9yIGhhcyBoYWQgdG8gbWFpbnRhaW4gdGhlaXIgb3duIHBy b3RvY29sIHN0YWNrIGFuZCBpbmRlcGVuZGVudGx5DQo+IGJ1aWxkIHRydXN0IGluIHRoZSBxdWFs aXR5IG9mIHRoZSBwcm90b2NvbC4gVGhlIHByaW1hcnkgZ29hbCBvZiB0aGlzDQo+IHdvcmtpbmcg Z3JvdXAgaXMgdG8gZGV2ZWxvcCBhIHN0YW5kYXJkIG1lc3NhZ2luZyBzZWN1cml0eSBwcm90b2Nv bA0KPiBzbyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gc2hhcmUgY29kZSwgYW5kIHNvIHRoYXQgdGhl cmUgY2FuIGJlIHNoYXJlZA0KPiB2YWxpZGF0aW9uIG9mIHRoZSBwcm90b2NvbCAoYXMgdGhlcmUg aGFzIGJlZW4gd2l0aCBUTFMgMS4zKS4NCj4NCj4gSXQgaXMgbm90IGEgZ29hbCBvZiB0aGlzIGdy b3VwIHRvIGVuYWJsZSBpbnRlcm9wZXJhYmlsaXR5IC8gZmVkZXJhdGlvbg0KPiBiZXR3ZWVuIG1l c3NhZ2luZyBhcHBsaWNhdGlvbnMgYmV5b25kIHRoZSBrZXkgZXN0YWJsaXNobWVudCwNCj4gYXV0 aGVudGljYXRpb24sIGFuZCBjb25maWRlbnRpYWxpdHkgc2VydmljZXMuICBGdWxsIGludGVyb3Bl cmFiaWxpdHkNCj4gd291bGQgcmVxdWlyZSBhbGlnbm1lbnQgYXQgbWFueSBkaWZmZXJlbnQgbGF5 ZXJzIGJleW9uZCBzZWN1cml0eSwNCj4gZS5nLiwgc3RhbmRhcmQgbWVzc2FnZSB0cmFuc3BvcnQg YW5kIGFwcGxpY2F0aW9uIHNlbWFudGljcy4gIFRoZQ0KPiBmb2N1cyBvZiB0aGlzIHdvcmsgaXMg dG8gZGV2ZWxvcCBhIG1lc3NhZ2luZyBzZWN1cml0eSBsYXllciB0aGF0DQo+IGRpZmZlcmVudCBh cHBsaWNhdGlvbnMgY2FuIGFkYXB0IHRvIHRoZWlyIG93biBuZWVkcy4NCj4NCj4gV2hpbGUgYXV0 aGVudGljYXRpb24gaXMgYSBrZXkgZ29hbCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAsIGl0IGlzIG5v dA0KPiB0aGUgb2JqZWN0aXZlIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBkZXZlbG9wIG5ldyBh dXRoZW50aWNhdGlvbg0KPiB0ZWNobm9sb2dpZXMuICBSYXRoZXIsIHRoZSBzZWN1cml0eSBwcm90 b2NvbCBkZXZlbG9wZWQgYnkgdGhpcw0KPiBncm91cCB3aWxsIHByb3ZpZGUgYSB3YXkgdG8gbGV2 ZXJhZ2UgZXhpc3RpbmcgYXV0aGVudGljYXRpb24NCj4gdGVjaG5vbG9naWVzIHRvIGFzc29jaWF0 ZSBpZGVudGl0aWVzIHdpdGgga2V5cyB1c2VkIGluIHRoZSBwcm90b2NvbCwNCj4ganVzdCBhcyBU TFMgZG9lcyB3aXRoIFguNTA5Lg0KPg0KPiBJbiBkZXZlbG9waW5nIHRoaXMgcHJvdG9jb2wsIHdl IHdpbGwgZHJhdyBvbiBsZXNzb25zIGxlYXJuZWQgZnJvbQ0KPiBzZXZlcmFsIHByaW9yIG1lc3Nh Z2Utb3JpZW50ZWQgc2VjdXJpdHkgcHJvdG9jb2xzLCBpbiBhZGRpdGlvbiB0bw0KPiB0aGUgcHJv cHJpZXRhcnkgbWVzc2FnaW5nIHNlY3VyaXR5IHByb3RvY29scyBkZXBsb3llZCB3aXRoaW4NCj4g ZXhpc3RpbmcgYXBwbGljYXRpb25zOg0KPg0KPiBvIFMvTUlNRSAtIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NzUxPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1NzUxJmQ9RHdNRmFRJmM9NVZE MFJUdE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmbT12THc3eVI4X0JI RVRIT20zZmNaZWplQXIzYUJacHZnM0hMOEc1VC1zbTdVJnM9YllwekloaTUtOHgycTg5SkowbE1p WnZycW04cFpQdDYtYkwxLTA1TkJiWSZlPT4NCj4gbyBPcGVuUEdQIC0gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzQ4ODA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzQ4ODAmZD1Ed01GYVEmYz01 VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXZMdzd5Ujhf QkhFVEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1Umcz15RWxRS3ZKNU52cVhzeERyX0xJ cklkUEl2bFBXTnRMSFpaLV9FOXJ4S1RFJmU9Pg0KPiBvIE9mZiB0aGUgUmVjb3JkIC0gaHR0cHM6 Ly9vdHIuY3lwaGVycHVua3MuY2EvUHJvdG9jb2wtdjMtNC4xLjEuaHRtbDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX290ci5jeXBoZXJwdW5rcy5j YV9Qcm90b2NvbC0yRHYzLTJENC4xLjEuaHRtbCZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQx YjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJm09dkx3N3lSOF9CSEVUSE9tM2ZjWmVqZUFy M2FCWnB2ZzNITDhHNVQtc203VSZzPXFHeVhzMmEtZGdjQVloQ2QtR1dkTktEWThZUXRqaTNhN0Iw UnZGV0dRZ00mZT0+DQo+IG8gU2lnbmFsIC0gaHR0cHM6Ly9zaWduYWwub3JnL2RvY3MvPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fc2lnbmFsLm9y Z19kb2NzXyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhf YnZFcU1hODRRJm09dkx3N3lSOF9CSEVUSE9tM2ZjWmVqZUFyM2FCWnB2ZzNITDhHNVQtc203VSZz PS1sNUJmTUJTZ2k1ZWh3Z3lKNWVWSUdzcERSMDQzWkVYaUU1NEN5YkVBQVUmZT0+DQo+DQo+IFRo ZSBpbnRlbnQgb2YgdGhpcyB3b3JraW5nIGdyb3VwIGlzIHRvIGZvbGxvdyB0aGUgcGF0dGVybiBv Zg0KPiBUTFMgMS4zLCB3aXRoIHNwZWNpZmljYXRpb24sIGltcGxlbWVudGF0aW9uLCBhbmQgdmVy aWZpY2F0aW9uDQo+IHByb2NlZWRpbmcgaW4gcGFyYWxsZWwuICBCeSB0aGUgdGltZSB3ZSBhcnJp dmUgYXQgUkZDLCB3ZQ0KPiBob3BlIHRvIGhhdmUgc2V2ZXJhbCBpbnRlcm9wZXJhYmxlIGltcGxl bWVudGF0aW9ucyBhcyB3ZWxsDQo+IGFzIGEgdGhvcm91Z2ggc2VjdXJpdHkgYW5hbHlzaXMuDQo+ DQo+IFRoZSBzcGVjaWZpY2F0aW9ucyBkZXZlbG9wZWQgYnkgdGhpcyB3b3JraW5nIGdyb3VwIHdp bGwgYmUNCj4gYmFzZWQgb24gcHJlLXN0YW5kYXJkaXphdGlvbiBpbXBsZW1lbnRhdGlvbiBhbmQg ZGVwbG95bWVudA0KPiBleHBlcmllbmNlLCBhbmQgZ2VuZXJhbGl6aW5nIHRoZSBkZXNpZ24gZGVz Y3JpYmVkIGluOg0KPg0KPiBvIGRyYWZ0LW9tYXJhLW1scy1hcmNoaXRlY3R1cmUNCj4gbyBkcmFm dC1iYXJuZXMtbWxzLXByb3RvY29sDQo+DQo+IE5vdGUgdGhhdCBjb25zZW5zdXMgaXMgcmVxdWly ZWQgYm90aCBmb3IgY2hhbmdlcyB0byB0aGUgY3VycmVudA0KPiBwcm90b2NvbCBtZWNoYW5pc21z IGFuZCByZXRlbnRpb24gb2YgY3VycmVudCBtZWNoYW5pc21zLiBJbg0KPiBwYXJ0aWN1bGFyLCBi ZWNhdXNlIHNvbWV0aGluZyBpcyBpbiB0aGUgaW5pdGlhbCBkb2N1bWVudCBzZXQgZG9lcw0KPiBu b3QgaW1wbHkgdGhhdCB0aGVyZSBpcyBjb25zZW5zdXMgYXJvdW5kIHRoZSBmZWF0dXJlIG9yIGFy b3VuZA0KPiBob3cgaXQgaXMgc3BlY2lmaWVkLg0KPg0KPiBNaWxlc3RvbmVzOg0KPiBNYXkgMjAx OCAtIEluaXRpYWwgd29ya2luZyBncm91cCBkb2N1bWVudHMgZm9yIGFyY2hpdGVjdHVyZSBhbmQg a2V5IG1hbmFnZW1lbnQNCj4gU2VwdCAyMDE4IC0gSW5pdGlhbCB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50IGFkb3B0ZWQgZm9yIG1lc3NhZ2UgcHJvdGVjdGlvbg0KPiBKYW4gMjAxOSAtIFN1Ym1pdCBh cmNoaXRlY3R1cmUgZG9jdW1lbnQgdG8gSUVTRyBhcyBJbmZvcm1hdGlvbmFsDQo+IEp1biAyMDE5 IC0gU3VibWl0IGtleSBtYW5hZ2VtZW50IHByb3RvY29sIHRvIElFU0cgYXMgUHJvcG9zZWQgU3Rh bmRhcmQNCj4gU2VwdCAyMDE5IC0gU3VibWl0IG1lc3NhZ2UgcHJvdGVjdGlvbiBwcm90b2NvbCB0 byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+IENoZWVycywNCj4NCj4gc3B0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNTFMgbWFpbGlu ZyBsaXN0DQpNTFNAaWV0Zi5vcmc8bWFpbHRvOk1MU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbWxz JmQ9RHdNRmFRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4 NFEmbT12THc3eVI4X0JIRVRIT20zZmNaZWplQXIzYUJacHZnM0hMOEc1VC1zbTdVJnM9ckNrTzZi akF1emtpY0FjQzl4UXd0d1dNS2h2b0drZU5jUnZYa3lMb3puZyZlPT4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxpc3QNCk1M U0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1Ed01GYVEm Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXZMdzd5 UjhfQkhFVEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1Umcz1yQ2tPNmJqQXV6a2ljQWND OXhRd3R3V01LaHZvR2tlTmNSdlhreUxvem5nJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxTQGlldGYub3Jn PG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1Ed01GYVEmYz01VkQwUlR0 TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXZMdzd5UjhfQkhFVEhP bTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1Umcz1yQ2tPNmJqQXV6a2ljQWNDOXhRd3R3V01L aHZvR2tlTmNSdlhreUxvem5nJmU9Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxT QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIz TVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXZMdzd5UjhfQkhFVEhPbTNmY1plamVBcjNh QlpwdmczSEw4RzVULXNtN1Umcz1yQ2tPNmJqQXV6a2ljQWNDOXhRd3R3V01LaHZvR2tlTmNSdlhr eUxvem5nJmU9Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk1MUyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0K aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1Ed0lDQWcmYz01VkQwUlR0TmxUaDN5Y2Q0 MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXZMdzd5UjhfQkhFVEhPbTNmY1plamVB cjNhQlpwdmczSEw4RzVULXNtN1Umcz1yQ2tPNmJqQXV6a2ljQWNDOXhRd3R3V01LaHZvR2tlTmNS dlhreUxvem5nJmU9DQo= --_000_EBC0A703D3454DD3B859C0BD1FD7660Afbcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpB d2Vzb21lLCBsb29rcyBnb29kIHRvIG1lLjxicj4NCjxicj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2Pg0KPGRpdj48YnI+DQpPbiAxOCBBcHIg MjAxOCwgYXQgMTg6MTUsIENhcyBDcmVtZXJzICZsdDs8YSBocmVmPSJtYWlsdG86Y2FzLmNyZW1l cnNAY3Mub3guYWMudWsiPmNhcy5jcmVtZXJzQGNzLm94LmFjLnVrPC9hPiZndDsgd3JvdGU6PGJy Pg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+RGVhciBhbGws DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFtIGFsc28gaGFwcHkgd2l0aCB0aGUgcmV2aXNp b25zLiBHb29kIHRvIGdvITwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2FzPGJyPg0K PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciI+T24gV2VkLCAx OCBBcHIgMjAxOCwgMTY6NDIgS2F0cmllbCBDb2huLUdvcmRvbiwgJmx0OzxhIGhyZWY9Im1haWx0 bzptZUBrYXRyaWVsLmNvLnVrIj5tZUBrYXRyaWVsLmNvLnVrPC9hPiZndDsgd3JvdGU6PGJyPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjx1 PjwvdT4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mIzQz OzE8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5PbiBXZWQsIDE4IEFwciAyMDE4LCBhdCA0OjM5IFBNLCBEYXZlIENyaWRsYW5k IHdyb3RlOjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2IGRpcj0ibHRyIj5MR1RNLjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYi Pk9uIDE4IEFwcmlsIDIwMTggYXQgMTY6MTgsIFJpY2hhcmQgQmFybmVzIDxzcGFuIGRpcj0ibHRy Ij4NCiZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBp cHYuc3g8L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tcmln aHQ6MHB4O21hcmdpbi1ib3R0b206MHB4O21hcmdpbi1sZWZ0OjAuOGV4O2JvcmRlci1sZWZ0LXdp ZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2PkhleSBT ZWFuLDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBsb29rcyBnb29k IHRvIG1lLiZuYnNwOyBTaGlwIGl0Ljxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+LS1SaWNoYXJkPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21h cmdpbi1yaWdodDowcHg7bWFyZ2luLWJvdHRvbTowcHg7bWFyZ2luLWxlZnQ6MC44ZXg7Ym9yZGVy LWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci1sZWZ0LWNvbG9y OnJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pk9uIEZyaSwgQXByIDEzLCAyMDE4IGF0IDI6NTIgUE0sIFNlYW4gVHVybmVyIDxzcGFu IGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIiB0YXJnZXQ9Il9i bGFuayI+c2VhbkBzbjNyZC5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tcmlnaHQ6 MHB4O21hcmdpbi1ib3R0b206MHB4O21hcmdpbi1sZWZ0OjAuOGV4O2JvcmRlci1sZWZ0LXdpZHRo OjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIw NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLXJpZ2h0OjBweDttYXJnaW4tYm90dG9tOjBweDttYXJn aW4tbGVmdDowLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29s aWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+U29y cnkgSSBtaXNzZWQgdG8gbWlub3IgZWRpdHMgZnJvbSBKb25hdGhhbiBMZW5ub3ggZGlkbuKAmXQg Z2V0IGNvcGllZCBvdmVyOjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+PHNwYW4+PGJyPg0KTWVzc2FnaW5nIExheWVyIFNlY3VyaXR5IChNTFMpIENo YXJ0ZXIgKERSQUZUKTxicj4NCjxicj4NClNldmVyYWwgSW50ZXJuZXQgYXBwbGljYXRpb25zIGhh dmUgYSBuZWVkIGZvciBncm91cCBrZXkgZXN0YWJsaXNobWVudDxicj4NCmFuZCBtZXNzYWdlIHBy b3RlY3Rpb24gcHJvdG9jb2xzIHdpdGggdGhlIGZvbGxvd2luZyBwcm9wZXJ0aWVzOjxicj4NCjxi cj4NCm8gTWVzc2FnZSBDb25maWRlbnRpYWxpdHkgLSBNZXNzYWdlcyBjYW4gb25seSBiZSByZWFk PGJyPg0KJm5ic3A7IGJ5IG1lbWJlcnMgb2YgdGhlIGdyb3VwPGJyPg0KbyBNZXNzYWdlIEludGVn cml0eSBhbmQgQXV0aGVudGljYXRpb24gLSBFYWNoIG1lc3NhZ2U8YnI+DQombmJzcDsgaGFzIGJl ZW4gc2VudCBieSBhbiBhdXRoZW50aWNhdGVkIHNlbmRlciwgYW5kIGhhczxicj4NCiZuYnNwOyBu b3QgYmVlbiB0YW1wZXJlZCB3aXRoPGJyPg0KbyBNZW1iZXJzaGlwIEF1dGhlbnRpY2F0aW9uIC0g RWFjaCBwYXJ0aWNpcGFudCBjYW4gdmVyaWZ5PGJyPg0KJm5ic3A7IHRoZSBzZXQgb2YgbWVtYmVy cyBpbiB0aGUgZ3JvdXA8YnI+DQpvIEFzeW5jaHJvbmljaXR5IC0gS2V5cyBjYW4gYmUgZXN0YWJs aXNoZWQgd2l0aG91dCBhbnk8YnI+DQombmJzcDsgdHdvIHBhcnRpY2lwYW50cyBiZWluZyBvbmxp bmUgYXQgdGhlIHNhbWUgdGltZTxicj4NCm8gRm9yd2FyZCBzZWNyZWN5IC0gRnVsbCBjb21wcm9t aXNlIG9mIGEgbm9kZSBhdCBhIHBvaW50PGJyPg0KJm5ic3A7IGluIHRpbWUgZG9lcyBub3QgcmV2 ZWFsIHBhc3QgbWVzc2FnZXMgc2VudCB3aXRoaW4gdGhlIGdyb3VwPGJyPg0KbyBQb3N0LWNvbXBy b21pc2Ugc2VjdXJpdHkgLSBGdWxsIGNvbXByb21pc2Ugb2YgYSBub2RlIGF0IGE8YnI+DQombmJz cDsgcG9pbnQgaW4gdGltZSBkb2VzIG5vdCByZXZlYWwgZnV0dXJlIG1lc3NhZ2VzIHNlbnQgd2l0 aGluIHRoZSBncm91cDxicj4NCjwvc3Bhbj5vIFNjYWxhYmlsaXR5IC0gUmVzb3VyY2UgcmVxdWly ZW1lbnRzIGhhdmUgZ29vZCBzY2FsaW5nIGluIHRoZTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4t cmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MHB4O21hcmdpbi1sZWZ0OjAuOGV4O2JvcmRlci1sZWZ0 LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2Io MjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLXJpZ2h0OjBweDttYXJnaW4tYm90dG9tOjBw eDttYXJnaW4tbGVmdDowLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5 bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6 MWV4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpnZW9yZ2lhLHNlcmlmIj4mbmJzcDsgc2l6ZSBvZiB0aGUgZ3JvdXAgKHByZWZlcmFibHkgc3Vi LWxpbmVhcik8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2Vy aWYiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+ U2V2ZXJhbCB3aWRlbHktZGVwbG95ZWQgYXBwbGljYXRpb25zIGhhdmUgZGV2ZWxvcGVkIHRoZWly IG93bjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+ cHJvdG9jb2xzIHRvIG1lZXQgdGhlc2UgbmVlZHMuIFdoaWxlIHRoZXNlIHByb3RvY29scyBhcmUg c2ltaWxhciw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2Vy aWYiPm5vIHR3byBhcmUgY2xvc2UgZW5vdWdoIHRvIGludGVyb3BlcmF0ZS4gQXMgYSByZXN1bHQs IGVhY2ggYXBwbGljYXRpb248YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdl b3JnaWEsc2VyaWYiPnZlbmRvciBoYXMgaGFkIHRvIG1haW50YWluIHRoZWlyIG93biBwcm90b2Nv bCBzdGFjayBhbmQgaW5kZXBlbmRlbnRseTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Z2VvcmdpYSxzZXJpZiI+YnVpbGQgdHJ1c3QgaW4gdGhlIHF1YWxpdHkgb2YgdGhlIHBy b3RvY29sLiBUaGUgcHJpbWFyeSBnb2FsIG9mIHRoaXM8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPndvcmtpbmcgZ3JvdXAgaXMgdG8gZGV2ZWxvcCBh IHN0YW5kYXJkIG1lc3NhZ2luZyBzZWN1cml0eSBwcm90b2NvbDxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+c28gdGhhdCBhcHBsaWNhdGlvbnMgY2Fu IHNoYXJlIGNvZGUsIGFuZCBzbyB0aGF0IHRoZXJlIGNhbiBiZSBzaGFyZWQ8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPnZhbGlkYXRpb24gb2YgdGhl IHByb3RvY29sIChhcyB0aGVyZSBoYXMgYmVlbiB3aXRoIFRMUyAxLjMpLg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPkl0IGlzIG5vdCBhIGdvYWwgb2Yg dGhpcyBncm91cCB0byBlbmFibGUgaW50ZXJvcGVyYWJpbGl0eSAvIGZlZGVyYXRpb248YnI+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPmJldHdlZW4gbWVz c2FnaW5nIGFwcGxpY2F0aW9ucyBiZXlvbmQgdGhlIGtleSBlc3RhYmxpc2htZW50LDxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+YXV0aGVudGljYXRp b24sIGFuZCBjb25maWRlbnRpYWxpdHkgc2VydmljZXMuJm5ic3A7IEZ1bGwgaW50ZXJvcGVyYWJp bGl0eTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+ d291bGQgcmVxdWlyZSBhbGlnbm1lbnQgYXQgbWFueSBkaWZmZXJlbnQgbGF5ZXJzIGJleW9uZCBz ZWN1cml0eSw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2Vy aWYiPmUuZy4sIHN0YW5kYXJkIG1lc3NhZ2UgdHJhbnNwb3J0IGFuZCBhcHBsaWNhdGlvbiBzZW1h bnRpY3MuJm5ic3A7IFRoZTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+Zm9jdXMgb2YgdGhpcyB3b3JrIGlzIHRvIGRldmVsb3AgYSBtZXNzYWdpbmcg c2VjdXJpdHkgbGF5ZXIgdGhhdDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Z2VvcmdpYSxzZXJpZiI+ZGlmZmVyZW50IGFwcGxpY2F0aW9ucyBjYW4gYWRhcHQgdG8gdGhlaXIg b3duIG5lZWRzLjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxz ZXJpZiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlm Ij5XaGlsZSBhdXRoZW50aWNhdGlvbiBpcyBhIGtleSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91 cCwgaXQgaXMgbm90PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lh LHNlcmlmIj50aGUgb2JqZWN0aXZlIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBkZXZlbG9wIG5l dyBhdXRoZW50aWNhdGlvbjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+dGVjaG5vbG9naWVzLiZuYnNwOyBSYXRoZXIsIHRoZSBzZWN1cml0eSBwcm90 b2NvbCBkZXZlbG9wZWQgYnkgdGhpczxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Z2VvcmdpYSxzZXJpZiI+Z3JvdXAgd2lsbCBwcm92aWRlIGEgd2F5IHRvIGxldmVyYWdlIGV4 aXN0aW5nIGF1dGhlbnRpY2F0aW9uPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpnZW9yZ2lhLHNlcmlmIj50ZWNobm9sb2dpZXMgdG8gYXNzb2NpYXRlIGlkZW50aXRpZXMgd2l0 aCBrZXlzIHVzZWQgaW4gdGhlIHByb3RvY29sLDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+anVzdCBhcyBUTFMgZG9lcyB3aXRoIFguNTA5Ljxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5JbiBkZXZlbG9waW5n IHRoaXMgcHJvdG9jb2wsIHdlIHdpbGwgZHJhdyBvbiBsZXNzb25zIGxlYXJuZWQgZnJvbTxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+c2V2ZXJhbCBw cmlvciBtZXNzYWdlLW9yaWVudGVkIHNlY3VyaXR5IHByb3RvY29scywgaW4gYWRkaXRpb24gdG88 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPnRoZSBw cm9wcmlldGFyeSBtZXNzYWdpbmcgc2VjdXJpdHkgcHJvdG9jb2xzIGRlcGxveWVkIHdpdGhpbjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+ZXhpc3Rp bmcgYXBwbGljYXRpb25zOjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lh LHNlcmlmIj5vIFMvTUlNRSAtIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1NzUxJmFtcDtk PUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZFSnlkQlZVWF9i dkVxTWE4NFEmYW1wO209dkx3N3lSOF9CSEVUSE9tM2ZjWmVqZUFyM2FCWnB2ZzNITDhHNVQtc203 VSZhbXA7cz1iWXB6SWhpNS04eDJxODlKSjBsTWladnJxbThwWlB0Ni1iTDEtMDVOQmJZJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NTE8 L2E+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5v IE9wZW5QR1AgLSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNDg4MCZhbXA7ZD1Ed01GYVEm YW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRR JmFtcDttPXZMdzd5UjhfQkhFVEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1UmYW1wO3M9 eUVsUUt2SjVOdnFYc3hEcl9MSXJJZFBJdmxQV050TEhaWi1fRTlyeEtURSZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0ODgwPC9hPjxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEs c2VyaWYiPm8gT2ZmIHRoZSBSZWNvcmQgLSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX290ci5jeXBoZXJwdW5rcy5jYV9Qcm90b2Nv bC0yRHYzLTJENC4xLjEuaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFi M01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXZMdzd5UjhfQkhFVEhPbTNm Y1plamVBcjNhQlpwdmczSEw4RzVULXNtN1UmYW1wO3M9cUd5WHMyYS1kZ2NBWWhDZC1HV2ROS0RZ OFlRdGppM2E3QjBSdkZXR1FnTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vb3Ry LmN5cGhlcnB1bmtzLi4uY2EvUHJvdG9jb2wtdjMtNC4xLjEuaHRtbDwvYT48YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDowcHg7bWFyZ2luLXJpZ2h0OjBweDttYXJnaW4tYm90dG9tOjBweDttYXJnaW4tbGVm dDowLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9y ZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1yaWdodDow cHg7bWFyZ2luLWJvdHRvbTowcHg7bWFyZ2luLWxlZnQ6MC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6 MXB4O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0 LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5vIFNpZ25hbCAtIDxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fc2lnbmFsLm9y Z19kb2NzXyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1N MENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXZMdzd5UjhfQkhFVEhPbTNmY1plamVBcjNhQlpw dmczSEw4RzVULXNtN1UmYW1wO3M9LWw1QmZNQlNnaTVlaHdneUo1ZVZJR3NwRFIwNDNaRVhpRTU0 Q3liRUFBVSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vc2lnbmFsLm9yZy9kb2Nz LzwvYT48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYi Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+VGhl IGludGVudCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgaXMgdG8gZm9sbG93IHRoZSBwYXR0ZXJuIG9m PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5UTFMg MS4zLCB3aXRoIHNwZWNpZmljYXRpb24sIGltcGxlbWVudGF0aW9uLCBhbmQgdmVyaWZpY2F0aW9u PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5wcm9j ZWVkaW5nIGluIHBhcmFsbGVsLiZuYnNwOyBCeSB0aGUgdGltZSB3ZSBhcnJpdmUgYXQgUkZDLCB3 ZTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+aG9w ZSB0byBoYXZlIHNldmVyYWwgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgYXMgd2VsbDxi cj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLXJpZ2h0OjBweDtt YXJnaW4tYm90dG9tOjBweDttYXJnaW4tbGVmdDowLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7 Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0 KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6MHB4O21hcmdpbi1yaWdodDowcHg7bWFyZ2luLWJvdHRvbTowcHg7bWFyZ2luLWxl ZnQ6MC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LXN0eWxlOnNvbGlkO2Jv cmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxz ZXJpZiI+YXMgYSB0aG9yb3VnaCBzZWN1cml0eSBhbmFseXNpcy4uPGJyPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjBweDttYXJnaW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MHB4 O21hcmdpbi1sZWZ0OjAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHls ZTpzb2xpZDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox ZXgiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFy Z2luLXJpZ2h0OjBweDttYXJnaW4tYm90dG9tOjBweDttYXJnaW4tbGVmdDowLjhleDtib3JkZXIt bGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6 cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj48YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPlRoZSBzcGVjaWZpY2F0 aW9ucyBkZXZlbG9wZWQgYnkgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgYmU8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPmJhc2VkIG9uIHByZS1zdGFu ZGFyZGl6YXRpb24gaW1wbGVtZW50YXRpb24gYW5kIGRlcGxveW1lbnQ8YnI+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6MHB4O21hcmdpbi1yaWdodDowcHg7bWFyZ2luLWJvdHRvbTow cHg7bWFyZ2luLWxlZnQ6MC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LXN0 eWxlOnNvbGlkO2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0 OjFleCI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjBweDtt YXJnaW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MHB4O21hcmdpbi1sZWZ0OjAuOGV4O2JvcmRl ci1sZWZ0LXdpZHRoOjFweDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1jb2xv cjpyZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5leHBlcmllbmNlLCBnZW5lcmFsaXpp bmcgdGhlIGRlc2lnbiBkZXNjcmliZWQgaW46PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj48c3Bhbj48YnI+DQpvIGRyYWZ0LW9tYXJhLW1scy1hcmNo aXRlY3R1cmU8YnI+DQpvIGRyYWZ0LWJhcm5lcy1tbHMtcHJvdG9jb2w8YnI+DQo8YnI+DQpOb3Rl IHRoYXQgY29uc2Vuc3VzIGlzIHJlcXVpcmVkIGJvdGggZm9yIGNoYW5nZXMgdG8gdGhlIGN1cnJl bnQ8YnI+DQpwcm90b2NvbCBtZWNoYW5pc21zIGFuZCByZXRlbnRpb24gb2YgY3VycmVudCBtZWNo YW5pc21zLiBJbjxicj4NCnBhcnRpY3VsYXIsIGJlY2F1c2Ugc29tZXRoaW5nIGlzIGluIHRoZSBp bml0aWFsIGRvY3VtZW50IHNldCBkb2VzPGJyPg0Kbm90IGltcGx5IHRoYXQgdGhlcmUgaXMgY29u c2Vuc3VzIGFyb3VuZCB0aGUgZmVhdHVyZSBvciBhcm91bmQ8YnI+DQpob3cgaXQgaXMgc3BlY2lm aWVkLjxicj4NCjxicj4NCk1pbGVzdG9uZXM6PGJyPg0KTWF5IDIwMTggLSBJbml0aWFsIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnRzIGZvciBhcmNoaXRlY3R1cmUgYW5kIGtleSBtYW5hZ2VtZW50PGJy Pg0KU2VwdCAyMDE4IC0gSW5pdGlhbCB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGFkb3B0ZWQgZm9y IG1lc3NhZ2UgcHJvdGVjdGlvbjxicj4NCkphbiAyMDE5IC0gU3VibWl0IGFyY2hpdGVjdHVyZSBk b2N1bWVudCB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWw8YnI+DQpKdW4gMjAxOSAtIFN1Ym1pdCBr ZXkgbWFuYWdlbWVudCBwcm90b2NvbCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0K U2VwdCAyMDE5IC0gU3VibWl0IG1lc3NhZ2UgcHJvdGVjdGlvbiBwcm90b2NvbCB0byBJRVNHIGFz IFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCnNwdDxicj4N Cjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBPbiBBcHIgMTMsIDIwMTgsIGF0IDE0OjA5LCBTZWFuIFR1 cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2VhbkBzbjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IEFsbCw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IFRoZSBjaGFydGVyIHR3ZWFrcyBt YWRlIHNpbmNlIHRoZSBCT0YgaW5jbHVkZSB0d2Vha2luZyAoYW5kIHJlb3JkZXJpbmcpIHNvbWUg b2YgdGhlIOKAnHByb3BlcnR54oCdIGJ1bGxldHM6PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IC0gYWRkZWQgbWVzc2FnZSBjb25maWRlbnRp YWxpdHk8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYi PiZndDsgLSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNoYW5nZWQgdG8gbWVzc2FnZSBpbnRlZ3Jp dHkgYW5kIGF1dGhlbnRpY2F0aW9uPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBJIGtub3cgdGhhdCBCZW4gU2Nod2FydHogbWVudGlvbmVk IHRoYXQgd2Ugc2hvdWxkIGxvb2sgYXQgb3VyIOKAnGZ1bGwgY29tcHJvbWlzZeKAnSBkZWZpbml0 aW9uLCBidXQgaW4gcmV2aWV3aW5nIGl0IHRoZSB3YXkgaXTigJlzIHVzZWQgaW4gRlMgYW5kIFBD UyBwcm9wZXJ0eSBidWxsZXRzIGl0IGxvb2tzIG9rYXkgdG8gbWUuJm5ic3A7IEJ1dCwgbWF5YmUg QmVuIGNhbiBlbGFib3JhdGUgYSBiaXQuPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBBbnl3YXkgYXQgdGhpcyBwb2ludCwgaGVyZeKAmXMg d2hhdCB3ZeKAmXJlIHdvcmtpbmcgd2l0aDo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgKE1M UykgQ2hhcnRlciAoRFJBRlQpPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpn ZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Z2VvcmdpYSxzZXJpZiI+Jmd0OyBTZXZlcmFsIEludGVybmV0IGFwcGxpY2F0aW9ucyBoYXZlIGEg bmVlZCBmb3IgZ3JvdXAga2V5IGVzdGFibGlzaG1lbnQ8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgYW5kIG1lc3NhZ2UgcHJvdGVjdGlvbiBw cm90b2NvbHMgd2l0aCB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBvIE1lc3NhZ2UgQ29uZmlk ZW50aWFsaXR5IC0gTWVzc2FnZXMgY2FuIG9ubHkgYmUgcmVhZDxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyZuYnNwOyAmbmJzcDtieSBtZW1i ZXJzIG9mIHRoZSBncm91cDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+Jmd0OyBvIE1lc3NhZ2UgSW50ZWdyaXR5IGFuZCBBdXRoZW50aWNhdGlvbiAt IEVhY2ggbWVzc2FnZTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vvcmdp YSxzZXJpZiI+Jmd0OyZuYnNwOyAmbmJzcDtoYXMgYmVlbiBzZW50IGJ5IGFuIGF1dGhlbnRpY2F0 ZWQgc2VuZGVyLCBhbmQgaGFzPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpn ZW9yZ2lhLHNlcmlmIj4mZ3Q7Jm5ic3A7ICZuYnNwO25vdCBiZWVuIHRhbXBlcmVkIHdpdGg8YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgbyBN ZW1iZXJzaGlwIEF1dGhlbnRpY2F0aW9uIC0gRWFjaCBwYXJ0aWNpcGFudCBjYW4gdmVyaWZ5PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7Jm5i c3A7ICZuYnNwO3RoZSBzZXQgb2YgbWVtYmVycyBpbiB0aGUgZ3JvdXA8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgbyBBc3luY2hyb25pY2l0 eSAtIEtleXMgY2FuIGJlIGVzdGFibGlzaGVkIHdpdGhvdXQgYW55PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7Jm5ic3A7ICZuYnNwO3R3byBw YXJ0aWNpcGFudHMgYmVpbmcgb25saW5lIGF0IHRoZSBzYW1lIHRpbWU8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgbyBGb3J3YXJkIHNlY3Jl Y3kgLSBGdWxsIGNvbXByb21pc2Ugb2YgYSBub2RlIGF0IGEgcG9pbnQ8YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsmbmJzcDsgJm5ic3A7aW4g dGltZSBkb2VzIG5vdCByZXZlYWwgcGFzdCBtZXNzYWdlcyBzZW50IHdpdGhpbiB0aGUgZ3JvdXA8 YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsg byBQb3N0LWNvbXByb21pc2Ugc2VjdXJpdHkgLSBGdWxsIGNvbXByb21pc2Ugb2YgYSBub2RlIGF0 IGE8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZn dDsmbmJzcDsgJm5ic3A7cG9pbnQgaW4gdGltZSBkb2VzIG5vdCByZXZlYWwgZnV0dXJlIG1lc3Nh Z2VzIHNlbnQgd2l0aGluIHRoZSBncm91cDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBvIFNjYWxhYmlsaXR5IC0gUmVzb3VyY2UgcmVxdWly ZW1lbnRzIHRoYXQgaGF2ZSBnb29kIHNjYWxpbmcgaW4gdGhlPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7Jm5ic3A7ICZuYnNwO3NpemUgb2Yg dGhlIGdyb3VwIChwcmVmZXJhYmx5IHN1Yi1saW5lYXIpPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBTZXZlcmFsIHdpZGVseS1kZXBsb3ll ZCBhcHBsaWNhdGlvbnMgaGF2ZSBkZXZlbG9wZWQgdGhlaXIgb3duPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHByb3RvY29scyB0byBtZWV0 IHRoZXNlIG5lZWRzLiBXaGlsZSB0aGVzZSBwcm90b2NvbHMgYXJlIHNpbWlsYXIsPGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IG5vIHR3byBh cmUgY2xvc2UgZW5vdWdoIHRvIGludGVyb3BlcmF0ZS4gQXMgYSByZXN1bHQsIGVhY2ggYXBwbGlj YXRpb248YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYi PiZndDsgdmVuZG9yIGhhcyBoYWQgdG8gbWFpbnRhaW4gdGhlaXIgb3duIHByb3RvY29sIHN0YWNr IGFuZCBpbmRlcGVuZGVudGx5PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpn ZW9yZ2lhLHNlcmlmIj4mZ3Q7IGJ1aWxkIHRydXN0IGluIHRoZSBxdWFsaXR5IG9mIHRoZSBwcm90 b2NvbC4gVGhlIHByaW1hcnkgZ29hbCBvZiB0aGlzPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJm b250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHdvcmtpbmcgZ3JvdXAgaXMgdG8gZGV2ZWxv cCBhIHN0YW5kYXJkIG1lc3NhZ2luZyBzZWN1cml0eSBwcm90b2NvbDxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBzbyB0aGF0IGFwcGxpY2F0 aW9ucyBjYW4gc2hhcmUgY29kZSwgYW5kIHNvIHRoYXQgdGhlcmUgY2FuIGJlIHNoYXJlZDxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyB2YWxp ZGF0aW9uIG9mIHRoZSBwcm90b2NvbCAoYXMgdGhlcmUgaGFzIGJlZW4gd2l0aCBUTFMgMS4zKS4N Cjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0 OyA8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZn dDsgSXQgaXMgbm90IGEgZ29hbCBvZiB0aGlzIGdyb3VwIHRvIGVuYWJsZSBpbnRlcm9wZXJhYmls aXR5IC8gZmVkZXJhdGlvbjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+Jmd0OyBiZXR3ZWVuIG1lc3NhZ2luZyBhcHBsaWNhdGlvbnMgYmV5b25kIHRo ZSBrZXkgZXN0YWJsaXNobWVudCw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 Omdlb3JnaWEsc2VyaWYiPiZndDsgYXV0aGVudGljYXRpb24sIGFuZCBjb25maWRlbnRpYWxpdHkg c2VydmljZXMuJm5ic3A7IEZ1bGwgaW50ZXJvcGVyYWJpbGl0eTxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyB3b3VsZCByZXF1aXJlIGFsaWdu bWVudCBhdCBtYW55IGRpZmZlcmVudCBsYXllcnMgYmV5b25kIHNlY3VyaXR5LDxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBlLmcuLCBzdGFu ZGFyZCBtZXNzYWdlIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gc2VtYW50aWNzLiZuYnNwOyBU aGU8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZn dDsgZm9jdXMgb2YgdGhpcyB3b3JrIGlzIHRvIGRldmVsb3AgYSBtZXNzYWdpbmcgc2VjdXJpdHkg bGF5ZXIgdGhhdDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxz ZXJpZiI+Jmd0OyBkaWZmZXJlbnQgYXBwbGljYXRpb25zIGNhbiBhZGFwdCB0byB0aGVpciBvd24g bmVlZHMuPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlm Ij4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJp ZiI+Jmd0OyBXaGlsZSBhdXRoZW50aWNhdGlvbiBpcyBhIGtleSBnb2FsIG9mIHRoaXMgd29ya2lu ZyBncm91cCwgaXQgaXMgbm90PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpn ZW9yZ2lhLHNlcmlmIj4mZ3Q7IHRoZSBvYmplY3RpdmUgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRv IGRldmVsb3AgbmV3IGF1dGhlbnRpY2F0aW9uPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHRlY2hub2xvZ2llcy4mbmJzcDsgUmF0aGVyLCB0 aGUgc2VjdXJpdHkgcHJvdG9jb2wgZGV2ZWxvcGVkIGJ5IHRoaXM8YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgZ3JvdXAgd2lsbCBwcm92aWRl IGEgd2F5IHRvIGxldmVyYWdlIGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uPGJyPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHRlY2hub2xvZ2llcyB0 byBhc3NvY2lhdGUgaWRlbnRpdGllcyB3aXRoIGtleXMgdXNlZCBpbiB0aGUgcHJvdG9jb2wsPGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IGp1 c3QgYXMgVExTIGRvZXMgd2l0aCBYLjUwOS48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IEluIGRldmVsb3BpbmcgdGhpcyBwcm90b2NvbCwg d2Ugd2lsbCBkcmF3IG9uIGxlc3NvbnMgbGVhcm5lZCBmcm9tPGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHNldmVyYWwgcHJpb3IgbWVzc2Fn ZS1vcmllbnRlZCBzZWN1cml0eSBwcm90b2NvbHMsIGluIGFkZGl0aW9uIHRvPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHRoZSBwcm9wcmll dGFyeSBtZXNzYWdpbmcgc2VjdXJpdHkgcHJvdG9jb2xzIGRlcGxveWVkIHdpdGhpbjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBleGlzdGlu ZyBhcHBsaWNhdGlvbnM6PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9y Z2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+Jmd0OyBvIFMvTUlNRSAtIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM1 NzUxJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZF SnlkQlZVWF9idkVxTWE4NFEmYW1wO209dkx3N3lSOF9CSEVUSE9tM2ZjWmVqZUFyM2FCWnB2ZzNI TDhHNVQtc203VSZhbXA7cz1iWXB6SWhpNS04eDJxODlKSjBsTWladnJxbThwWlB0Ni1iTDEtMDVO QmJZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzU3NTE8L2E+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lh LHNlcmlmIj4mZ3Q7IG8gT3BlblBHUCAtIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM0ODgw JmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZFSnlk QlZVWF9idkVxTWE4NFEmYW1wO209dkx3N3lSOF9CSEVUSE9tM2ZjWmVqZUFyM2FCWnB2ZzNITDhH NVQtc203VSZhbXA7cz15RWxRS3ZKNU52cVhzeERyX0xJcklkUEl2bFBXTnRMSFpaLV9FOXJ4S1RF JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzQ4ODA8L2E+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNl cmlmIj4mZ3Q7IG8gT2ZmIHRoZSBSZWNvcmQgLSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX290ci5jeXBoZXJwdW5rcy5jYV9Qcm90 b2NvbC0yRHYzLTJENC4xLjEuaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNk NDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXZMdzd5UjhfQkhFVEhP bTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1UmYW1wO3M9cUd5WHMyYS1kZ2NBWWhDZC1HV2RO S0RZOFlRdGppM2E3QjBSdkZXR1FnTSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v b3RyLmN5cGhlcnB1bmtzLmNhL1Byb3RvY29sLXYzLTQuMS4xLmh0bWw8L2E+PGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IG8gU2lnbmFsIC0g PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19zaWduYWwub3JnX2RvY3NfJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0 MWIzTVV3JmFtcDtyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1wO209dkx3N3lSOF9CSEVUSE9t M2ZjWmVqZUFyM2FCWnB2ZzNITDhHNVQtc203VSZhbXA7cz0tbDVCZk1CU2dpNWVod2d5SjVlVklH c3BEUjA0M1pFWGlFNTRDeWJFQUFVJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9z aWduYWwub3JnL2RvY3MvPC9hPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Z2VvcmdpYSxzZXJpZiI+Jmd0OyA8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 Omdlb3JnaWEsc2VyaWYiPiZndDsgVGhlIGludGVudCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgaXMg dG8gZm9sbG93IHRoZSBwYXR0ZXJuIG9mPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IFRMUyAxLjMsIHdpdGggc3BlY2lmaWNhdGlvbiwgaW1w bGVtZW50YXRpb24sIGFuZCB2ZXJpZmljYXRpb248YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgcHJvY2VlZGluZyBpbiBwYXJhbGxlbC4mbmJz cDsgQnkgdGhlIHRpbWUgd2UgYXJyaXZlIGF0IFJGQywgd2U8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgaG9wZSB0byBoYXZlIHNldmVyYWwg aW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgYXMgd2VsbDxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBhcyBhIHRob3JvdWdoIHNlY3Vy aXR5IGFuYWx5c2lzLjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vvcmdp YSxzZXJpZiI+Jmd0OyA8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3Jn aWEsc2VyaWYiPiZndDsgVGhlIHNwZWNpZmljYXRpb25zIGRldmVsb3BlZCBieSB0aGlzIHdvcmtp bmcgZ3JvdXAgd2lsbCBiZTxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+Jmd0OyBiYXNlZCBvbiBwcmUtc3RhbmRhcmRpemF0aW9uIGltcGxlbWVudGF0 aW9uIGFuZCBkZXBsb3ltZW50PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpn ZW9yZ2lhLHNlcmlmIj4mZ3Q7IGV4cGVyaWVuY2UsIGFuZCBnZW5lcmFsaXppbmcgdGhlIGRlc2ln biBkZXNjcmliZWQgaW46PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9y Z2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2Vv cmdpYSxzZXJpZiI+Jmd0OyBvIGRyYWZ0LW9tYXJhLW1scy1hcmNoaXRlY3R1cmU8YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgbyBkcmFmdC1i YXJuZXMtbWxzLXByb3RvY29sPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpn ZW9yZ2lhLHNlcmlmIj4mZ3Q7IDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Z2VvcmdpYSxzZXJpZiI+Jmd0OyBOb3RlIHRoYXQgY29uc2Vuc3VzIGlzIHJlcXVpcmVkIGJvdGgg Zm9yIGNoYW5nZXMgdG8gdGhlIGN1cnJlbnQ8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgcHJvdG9jb2wgbWVjaGFuaXNtcyBhbmQgcmV0ZW50 aW9uIG9mIGN1cnJlbnQgbWVjaGFuaXNtcy4gSW48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgcGFydGljdWxhciwgYmVjYXVzZSBzb21ldGhp bmcgaXMgaW4gdGhlIGluaXRpYWwgZG9jdW1lbnQgc2V0IGRvZXM8YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgbm90IGltcGx5IHRoYXQgdGhl cmUgaXMgY29uc2Vuc3VzIGFyb3VuZCB0aGUgZmVhdHVyZSBvciBhcm91bmQ8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgaG93IGl0IGlzIHNw ZWNpZmllZC48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2Vy aWYiPiZndDsgPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNl cmlmIj4mZ3Q7IE1pbGVzdG9uZXM6PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IE1heSAyMDE4IC0gSW5pdGlhbCB3b3JraW5nIGdyb3VwIGRv Y3VtZW50cyBmb3IgYXJjaGl0ZWN0dXJlIGFuZCBrZXkgbWFuYWdlbWVudDxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBTZXB0IDIwMTggLSBJ bml0aWFsIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgYWRvcHRlZCBmb3IgbWVzc2FnZSBwcm90ZWN0 aW9uPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4m Z3Q7IEphbiAyMDE5IC0gU3VibWl0IGFyY2hpdGVjdHVyZSBkb2N1bWVudCB0byBJRVNHIGFzIElu Zm9ybWF0aW9uYWw8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEs c2VyaWYiPiZndDsgSnVuIDIwMTkgLSBTdWJtaXQga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wgdG8g SUVTRyBhcyBQcm9wb3NlZCBTdGFuZGFyZDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Z2VvcmdpYSxzZXJpZiI+Jmd0OyBTZXB0IDIwMTkgLSBTdWJtaXQgbWVzc2FnZSBwcm90 ZWN0aW9uIHByb3RvY29sIHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgPGJyPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IENoZWVycyw8YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPiZndDsgPGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj4mZ3Q7IHNw dDxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGJy Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+TUxTIG1haWxpbmcgbGlzdDxicj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+PGEgaHJlZj0i bWFpbHRvOk1MU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPjxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbWxzJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0 TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1wO209dkx3N3lS OF9CSEVUSE9tM2ZjWmVqZUFyM2FCWnB2ZzNITDhHNVQtc203VSZhbXA7cz1yQ2tPNmJqQXV6a2lj QWNDOXhRd3R3V01LaHZvR2tlTmNSdlhreUxvem5nJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9hPjxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDowcHg7bWFyZ2luLXJpZ2h0OjBweDttYXJnaW4tYm90dG9t OjBweDttYXJnaW4tbGVmdDowLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQt c3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPjxicj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Z2VvcmdpYSxzZXJpZiI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPk1MUyBtYWlsaW5nIGxpc3Q8YnI+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPjxhIGhyZWY9Im1haWx0 bzpNTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5NTFNAaWV0Zi5vcmc8L2E+PGJyPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpnZW9yZ2lhLHNlcmlmIj48YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgz eWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXZMdzd5UjhfQkhF VEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1UmYW1wO3M9ckNrTzZiakF1emtpY0FjQzl4 UXd0d1dNS2h2b0drZU5jUnZYa3lMb3puZyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczwvYT48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWYiPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48dT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvdT48YnI+DQo8L2Rpdj4NCjxkaXY+TUxTIG1haWxpbmcgbGlz dDxicj4NCjwvZGl2Pg0KPGRpdj48YSBocmVmPSJtYWlsdG86TUxTQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+TUxTQGlldGYub3JnPC9hPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fbWxzJmFtcDtkPUR3TUZhUSZhbXA7Yz01VkQwUlR0TmxUaDN5 Y2Q0MWIzTVV3JmFtcDtyPU0wQ1ZFSnlkQlZVWF9idkVxTWE4NFEmYW1wO209dkx3N3lSOF9CSEVU SE9tM2ZjWmVqZUFyM2FCWnB2ZzNITDhHNVQtc203VSZhbXA7cz1yQ2tPNmJqQXV6a2ljQWNDOXhR d3R3V01LaHZvR2tlTmNSdlhreUxvem5nJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYuLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczwvYT48YnI+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpNTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk1MU0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5s VGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXZMdzd5Ujhf QkhFVEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVULXNtN1UmYW1wO3M9ckNrTzZiakF1emtpY0Fj Qzl4UXd0d1dNS2h2b0drZU5jUnZYa3lMb3puZyZhbXA7ZT0iIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWxzPC9h Pjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5NTFMgbWFp bGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpNTFNAaWV0Zi5vcmci Pk1MU0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19tbHMmYW1wO2Q9RHdJQ0FnJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNN VXcmYW1wO3I9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT12THc3eVI4X0JIRVRIT20zZmNa ZWplQXIzYUJacHZnM0hMOEc1VC1zbTdVJmFtcDtzPXJDa082YmpBdXpraWNBY0M5eFF3dHdXTUto dm9Ha2VOY1J2WGt5TG96bmcmYW1wO2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZh bXA7ZD1Ed0lDQWcmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJW VVhfYnZFcU1hODRRJmFtcDttPXZMdzd5UjhfQkhFVEhPbTNmY1plamVBcjNhQlpwdmczSEw4RzVU LXNtN1UmYW1wO3M9ckNrTzZiakF1emtpY0FjQzl4UXd0d1dNS2h2b0drZU5jUnZYa3lMb3puZyZh bXA7ZT08L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_EBC0A703D3454DD3B859C0BD1FD7660Afbcom_-- From nobody Thu Apr 19 00:28:21 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0812D77B for ; Thu, 19 Apr 2018 00:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 5VqKOSUiCrpu for ; Thu, 19 Apr 2018 00:28:16 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 2235E12422F for ; Thu, 19 Apr 2018 00:28:16 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id l2-v6so4007471iog.9 for ; Thu, 19 Apr 2018 00:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AJObF2pgcIIN8bpJXcBbGhW+Hi04EOuTBc6E58fuSow=; b=iLZJ0npHm3/ZHjqKHIaIBmGOOP8jYqxsUC4QlgsR/LBijHEUJliTmgaDjtJ3VAwAsw futvXGY22EzNEGjCnhnSP1bCCIiUVBjCognZpHlELJ+U365QdO+sAyki4y12W6Mp85FT t25cH8IcduSiZBJNhlCNHZHyoJfzoKBBpMsxP4s5rlCMEjaxKxvvF2pYPG+PVTf6EbVZ +lhlksePykH4oIgCySNRbf/jbv9UbNJQgLIalvmQ+DqN2bbsmPS4SHoswqggqa7ra4pY 5UBNJaWJPw8BQ0QOIoI7xae7u47FI4hGtrqJZv7wNOSkCz2II6tzEyaHIMUI6tVjic1t wxEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AJObF2pgcIIN8bpJXcBbGhW+Hi04EOuTBc6E58fuSow=; b=rR8/TN/Mh1LcMFg9DNaXs4byCWHULXiKynYvcG3uzPABOBZlXIxf6yAfUPrmLNn0WQ 2CS+uPYh1+XkvheC4syMrYYg1tZ3z+tsKqzWtok7A14ks00qz2HAJpKsoourb2RDZAMg D3RBmQJO7bN9Lt7I1A9nUQMqmdy3DzIEjrZ5mglo6/enBmPqx+WAe2S3LAC0j6nmiquM F7c/d21mVt1zjoGNiAp2wusiQVfIlrlPh6rjeyD1TqlbTyzNAekX0n7zD8qWiMtqjlNq kgKkcKtqW9GiZMYgjc0uG1uf/qVhXIPUvRz3ByqOBMSgjbOprmOwLN0mvK/de1tST03C D2wg== X-Gm-Message-State: ALQs6tDwr58JMGndIEs4SgU8eX3XkgF7V2EnGH+glcrthm1DYyhC5PRZ iuv+9RHdY7jzm0Aj1SHrH2HvxaIJnwubd+UagiH6 X-Google-Smtp-Source: AIpwx49Jr3n66eqlDv5sp2MUU9yEy1jX6RyS6fCU6JoSU4fNCDhh3KfKsN2a97N5c7dwNmhFFx/yTHzbz8Jmh4SkCKM= X-Received: by 2002:a6b:c582:: with SMTP id v124-v6mr5329006iof.55.1524122894860; Thu, 19 Apr 2018 00:28:14 -0700 (PDT) MIME-Version: 1.0 References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com> In-Reply-To: From: Emad Omara Date: Thu, 19 Apr 2018 07:28:03 +0000 Message-ID: To: Jon Millican Cc: Cas Cremers , Katriel Cohn-Gordon , "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bebe6b056a2e8370" Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 07:28:20 -0000 --000000000000bebe6b056a2e8370 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable LGTM On Thu, Apr 19, 2018 at 7:33 AM Jon Millican wrote: > Awesome, looks good to me. > > Sent from my iPhone > > On 18 Apr 2018, at 18:15, Cas Cremers wrote: > > Dear all, > > I am also happy with the revisions. Good to go! > > Cas > > On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, wrote: > >> +1 >> >> >> On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote: >> >> LGTM. >> >> On 18 April 2018 at 16:18, Richard Barnes wrote: >> >> Hey Sean, >> >> This looks good to me. Ship it. >> >> --Richard >> >> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner wrote: >> >> Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t get co= pied over: >> >> Messaging Layer Security (MLS) Charter (DRAFT) >> >> Several Internet applications have a need for group key establishment >> and message protection protocols with the following properties: >> >> o Message Confidentiality - Messages can only be read >> by members of the group >> o Message Integrity and Authentication - Each message >> has been sent by an authenticated sender, and has >> not been tampered with >> o Membership Authentication - Each participant can verify >> the set of members in the group >> o Asynchronicity - Keys can be established without any >> two participants being online at the same time >> o Forward secrecy - Full compromise of a node at a point >> in time does not reveal past messages sent within the group >> o Post-compromise security - Full compromise of a node at a >> point in time does not reveal future messages sent within the group >> o Scalability - Resource requirements have good scaling in the >> >> size of the group (preferably sub-linear) >> >> Several widely-deployed applications have developed their own >> protocols to meet these needs. While these protocols are similar, >> no two are close enough to interoperate. As a result, each application >> vendor has had to maintain their own protocol stack and independently >> build trust in the quality of the protocol. The primary goal of this >> working group is to develop a standard messaging security protocol >> so that applications can share code, and so that there can be shared >> validation of the protocol (as there has been with TLS 1.3). >> >> It is not a goal of this group to enable interoperability / federation >> between messaging applications beyond the key establishment, >> authentication, and confidentiality services. Full interoperability >> would require alignment at many different layers beyond security, >> e.g., standard message transport and application semantics. The >> focus of this work is to develop a messaging security layer that >> different applications can adapt to their own needs. >> >> While authentication is a key goal of this working group, it is not >> the objective of this working group to develop new authentication >> technologies. Rather, the security protocol developed by this >> group will provide a way to leverage existing authentication >> technologies to associate identities with keys used in the protocol, >> just as TLS does with X.509. >> >> In developing this protocol, we will draw on lessons learned from >> several prior message-oriented security protocols, in addition to >> the proprietary messaging security protocols deployed within >> existing applications: >> >> o S/MIME - https://tools.ietf.org/html/rfc5751 >> >> o OpenPGP - https://tools.ietf.org/html/rfc4880 >> >> o Off the Record - https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html >> >> >> >> o Signal - https://signal.org/docs/ >> >> >> The intent of this working group is to follow the pattern of >> TLS 1.3, with specification, implementation, and verification >> proceeding in parallel. By the time we arrive at RFC, we >> hope to have several interoperable implementations as well >> >> as a thorough security analysis.. >> >> >> The specifications developed by this working group will be >> based on pre-standardization implementation and deployment >> >> experience, generalizing the design described in: >> >> o draft-omara-mls-architecture >> o draft-barnes-mls-protocol >> >> Note that consensus is required both for changes to the current >> protocol mechanisms and retention of current mechanisms. In >> particular, because something is in the initial document set does >> not imply that there is consensus around the feature or around >> how it is specified. >> >> Milestones: >> May 2018 - Initial working group documents for architecture and key >> management >> Sept 2018 - Initial working group document adopted for message protectio= n >> Jan 2019 - Submit architecture document to IESG as Informational >> Jun 2019 - Submit key management protocol to IESG as Proposed Standard >> Sept 2019 - Submit message protection protocol to IESG as Proposed >> Standard >> >> Cheers, >> >> spt >> >> > On Apr 13, 2018, at 14:09, Sean Turner wrote: >> > >> > All, >> > >> > The charter tweaks made since the BOF include tweaking (and reordering= ) >> some of the =E2=80=9Cproperty=E2=80=9D bullets: >> > - added message confidentiality >> > - message authentication changed to message integrity and authenticati= on >> > >> > I know that Ben Schwartz mentioned that we should look at our =E2=80= =9Cfull >> compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99s= used in FS and PCS >> property bullets it looks okay to me. But, maybe Ben can elaborate a bi= t. >> > >> > Anyway at this point, here=E2=80=99s what we=E2=80=99re working with: >> > >> > >> > Messaging Layer Security (MLS) Charter (DRAFT) >> > >> > Several Internet applications have a need for group key establishment >> > and message protection protocols with the following properties: >> > >> > o Message Confidentiality - Messages can only be read >> > by members of the group >> > o Message Integrity and Authentication - Each message >> > has been sent by an authenticated sender, and has >> > not been tampered with >> > o Membership Authentication - Each participant can verify >> > the set of members in the group >> > o Asynchronicity - Keys can be established without any >> > two participants being online at the same time >> > o Forward secrecy - Full compromise of a node at a point >> > in time does not reveal past messages sent within the group >> > o Post-compromise security - Full compromise of a node at a >> > point in time does not reveal future messages sent within the group >> > o Scalability - Resource requirements that have good scaling in the >> > size of the group (preferably sub-linear) >> > >> > Several widely-deployed applications have developed their own >> > protocols to meet these needs. While these protocols are similar, >> > no two are close enough to interoperate. As a result, each application >> > vendor has had to maintain their own protocol stack and independently >> > build trust in the quality of the protocol. The primary goal of this >> > working group is to develop a standard messaging security protocol >> > so that applications can share code, and so that there can be shared >> > validation of the protocol (as there has been with TLS 1.3). >> > >> > It is not a goal of this group to enable interoperability / federation >> > between messaging applications beyond the key establishment, >> > authentication, and confidentiality services. Full interoperability >> > would require alignment at many different layers beyond security, >> > e.g., standard message transport and application semantics. The >> > focus of this work is to develop a messaging security layer that >> > different applications can adapt to their own needs. >> > >> > While authentication is a key goal of this working group, it is not >> > the objective of this working group to develop new authentication >> > technologies. Rather, the security protocol developed by this >> > group will provide a way to leverage existing authentication >> > technologies to associate identities with keys used in the protocol, >> > just as TLS does with X.509. >> > >> > In developing this protocol, we will draw on lessons learned from >> > several prior message-oriented security protocols, in addition to >> > the proprietary messaging security protocols deployed within >> > existing applications: >> > >> > o S/MIME - https://tools.ietf.org/html/rfc5751 >> >> > o OpenPGP - https://tools.ietf.org/html/rfc4880 >> >> > o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html >> >> > o Signal - https://signal.org/docs/ >> >> > >> > The intent of this working group is to follow the pattern of >> > TLS 1.3, with specification, implementation, and verification >> > proceeding in parallel. By the time we arrive at RFC, we >> > hope to have several interoperable implementations as well >> > as a thorough security analysis. >> > >> > The specifications developed by this working group will be >> > based on pre-standardization implementation and deployment >> > experience, and generalizing the design described in: >> > >> > o draft-omara-mls-architecture >> > o draft-barnes-mls-protocol >> > >> > Note that consensus is required both for changes to the current >> > protocol mechanisms and retention of current mechanisms. In >> > particular, because something is in the initial document set does >> > not imply that there is consensus around the feature or around >> > how it is specified. >> > >> > Milestones: >> > May 2018 - Initial working group documents for architecture and key >> management >> > Sept 2018 - Initial working group document adopted for message >> protection >> > Jan 2019 - Submit architecture document to IESG as Informational >> > Jun 2019 - Submit key management protocol to IESG as Proposed Standard >> > Sept 2019 - Submit message protection protocol to IESG as Proposed >> Standard >> > >> > Cheers, >> > >> > spt >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> >> *_______________________________________________* >> MLS mailing list >> MLS@ietf.org >> >> https://www.ietf..org/mailman/listinfo/mls >> >> >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> >> > _______________________________________________ > MLS mailing list > MLS@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvEq= Ma84Q&m=3DvLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=3DrCkO6bjAuzkicAcC9= xQwtwWMKhvoGkeNcRvXkyLozng&e=3D > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000bebe6b056a2e8370 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM


On Thu, Apr 19, 2018 at 7:33 AM Jon Millican <jmillican@fb.com> wrote:
Awesome, looks good to me.

Sent from my iPhone

On 18 Apr 2018, at 18:15, Cas Cremers <cas.cremers@cs.ox.ac.uk> wrote:

Dear all,

I am also happy with the revisions. Good to go!

Cas

On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <me@katriel.co.uk> wrote:
+1


On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote:
LGTM.

On 18 April 2018 at 16:18, Richard= Barnes <rlb@ipv.sx> wrote:
Hey Sean,

This looks good to me.=C2=A0 Ship it.

--Richard
On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <sean@sn3rd.com> wrote:
Sorry I missed to minor edits from= Jonathan Lennox didn=E2=80=99t get copied over:

Messaging Layer Security (MLS) Charter (DRAFT)

Several Internet applications have a need for group key establishment
and message protection protocols with the following properties:

o Message Confidentiality - Messages can only be read
=C2=A0 by members of the group
o Message Integrity and Authentication - Each message
=C2=A0 has been sent by an authenticated sender, and has
=C2=A0 not been tampered with
o Membership Authentication - Each participant can verify
=C2=A0 the set of members in the group
o Asynchronicity - Keys can be established without any
=C2=A0 two participants being online at the same time
o Forward secrecy - Full compromise of a node at a point
=C2=A0 in time does not reveal past messages sent within the group
o Post-compromise security - Full compromise of a node at a
=C2=A0 point in time does not reveal future messages sent within the group<= br> o Scalability - Resource requirements have good scaling in the
=C2=A0 size of the group (preferab= ly sub-linear)

Several widely-deployed applicatio= ns have developed their own
protocols to meet these needs. Whi= le these protocols are similar,
no two are close enough to interop= erate. As a result, each application
vendor has had to maintain their o= wn protocol stack and independently
build trust in the quality of the = protocol. The primary goal of this
working group is to develop a stan= dard messaging security protocol
so that applications can share cod= e, and so that there can be shared
validation of the protocol (as the= re has been with TLS 1.3).

It is not a goal of this group to = enable interoperability / federation
between messaging applications bey= ond the key establishment,
authentication, and confidentialit= y services.=C2=A0 Full interoperability
would require alignment at many di= fferent layers beyond security,
e.g., standard message transport a= nd application semantics.=C2=A0 The
focus of this work is to develop a= messaging security layer that
different applications can adapt t= o their own needs.

While authentication is a key goal= of this working group, it is not
the objective of this working grou= p to develop new authentication
technologies.=C2=A0 Rather, the se= curity protocol developed by this
group will provide a way to levera= ge existing authentication
technologies to associate identiti= es with keys used in the protocol,
just as TLS does with X.509.

In developing this protocol, we wi= ll draw on lessons learned from
several prior message-oriented sec= urity protocols, in addition to
the proprietary messaging security= protocols deployed within
existing applications:



The intent of this working group i= s to follow the pattern of
TLS 1.3, with specification, imple= mentation, and verification
proceeding in parallel.=C2=A0 By t= he time we arrive at RFC, we
hope to have several interoperable= implementations as well
as a thorough security analysis..<= br>

The specifications developed by th= is working group will be
based on pre-standardization imple= mentation and deployment
experience, generalizing the desig= n described in:

o draft-omara-mls-architecture
o draft-barnes-mls-protocol

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In
particular, because something is in the initial document set does
not imply that there is consensus around the feature or around
how it is specified.

Milestones:
May 2018 - Initial working group documents for architecture and key managem= ent
Sept 2018 - Initial working group document adopted for message protection Jan 2019 - Submit architecture document to IESG as Informational
Jun 2019 - Submit key management protocol to IESG as Proposed Standard
Sept 2019 - Submit message protection protocol to IESG as Proposed Standard=

Cheers,

spt

> On Apr 13, 2018, at 14:09, Se= an Turner <sean@sn3r= d.com> wrote:
>
> All,
>
> The charter tweaks made since= the BOF include tweaking (and reordering) some of the =E2=80=9Cproperty=E2= =80=9D bullets:
> - added message confidentiali= ty
> - message authentication chan= ged to message integrity and authentication
>
> I know that Ben Schwartz ment= ioned that we should look at our =E2=80=9Cfull compromise=E2=80=9D definiti= on, but in reviewing it the way it=E2=80=99s used in FS and PCS property bu= llets it looks okay to me.=C2=A0 But, maybe Ben can elaborate a bit.
>
> Anyway at this point, here=E2= =80=99s what we=E2=80=99re working with:
>
>
> Messaging Layer Security (MLS= ) Charter (DRAFT)
>
> Several Internet applications= have a need for group key establishment
> and message protection protoc= ols with the following properties:
>
> o Message Confidentiality - M= essages can only be read
>=C2=A0 =C2=A0by members of the= group
> o Message Integrity and Authe= ntication - Each message
>=C2=A0 =C2=A0has been sent by = an authenticated sender, and has
>=C2=A0 =C2=A0not been tampered= with
> o Membership Authentication -= Each participant can verify
>=C2=A0 =C2=A0the set of member= s in the group
> o Asynchronicity - Keys can b= e established without any
>=C2=A0 =C2=A0two participants = being online at the same time
> o Forward secrecy - Full comp= romise of a node at a point
>=C2=A0 =C2=A0in time does not = reveal past messages sent within the group
> o Post-compromise security - = Full compromise of a node at a
>=C2=A0 =C2=A0point in time doe= s not reveal future messages sent within the group
> o Scalability - Resource requ= irements that have good scaling in the
>=C2=A0 =C2=A0size of the group= (preferably sub-linear)
>
> Several widely-deployed appli= cations have developed their own
> protocols to meet these needs= . While these protocols are similar,
> no two are close enough to in= teroperate. As a result, each application
> vendor has had to maintain th= eir own protocol stack and independently
> build trust in the quality of= the protocol. The primary goal of this
> working group is to develop a= standard messaging security protocol
> so that applications can shar= e code, and so that there can be shared
> validation of the protocol (a= s there has been with TLS 1.3).
>
> It is not a goal of this grou= p to enable interoperability / federation
> between messaging application= s beyond the key establishment,
> authentication, and confident= iality services.=C2=A0 Full interoperability
> would require alignment at ma= ny different layers beyond security,
> e.g., standard message transp= ort and application semantics.=C2=A0 The
> focus of this work is to deve= lop a messaging security layer that
> different applications can ad= apt to their own needs.
>
> While authentication is a key= goal of this working group, it is not
> the objective of this working= group to develop new authentication
> technologies.=C2=A0 Rather, t= he security protocol developed by this
> group will provide a way to l= everage existing authentication
> technologies to associate ide= ntities with keys used in the protocol,
> just as TLS does with X.509.<= br>
>
> In developing this protocol, = we will draw on lessons learned from
> several prior message-oriente= d security protocols, in addition to
> the proprietary messaging sec= urity protocols deployed within
> existing applications:
>
>
> The intent of this working gr= oup is to follow the pattern of
> TLS 1.3, with specification, = implementation, and verification
> proceeding in parallel.=C2=A0= By the time we arrive at RFC, we
> hope to have several interope= rable implementations as well
> as a thorough security analys= is.
>
> The specifications developed = by this working group will be
> based on pre-standardization = implementation and deployment
> experience, and generalizing = the design described in:
>
> o draft-omara-mls-architectur= e
> o draft-barnes-mls-protocol
>
> Note that consensus is requir= ed both for changes to the current
> protocol mechanisms and reten= tion of current mechanisms. In
> particular, because something= is in the initial document set does
> not imply that there is conse= nsus around the feature or around
> how it is specified.
>
> Milestones:
> May 2018 - Initial working gr= oup documents for architecture and key management
> Sept 2018 - Initial working g= roup document adopted for message protection
> Jan 2019 - Submit architectur= e document to IESG as Informational
> Jun 2019 - Submit key managem= ent protocol to IESG as Proposed Standard
> Sept 2019 - Submit message pr= otection protocol to IESG as Proposed Standard
>
> Cheers,
>
> spt

__________________________________= _____________
MLS mailing list

__________________________________= _____________
MLS mailing list

_______________________________________________
MLS mailing list
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
______________= _________________________________
MLS mailing list
MLS@ietf.org
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000bebe6b056a2e8370-- From nobody Thu Apr 19 01:31:29 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8236E1270AE for ; Thu, 19 Apr 2018 01:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com 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 pyalZs5QAYkj for ; Thu, 19 Apr 2018 01:31:23 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 171B0126C25 for ; Thu, 19 Apr 2018 01:31:23 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id z73-v6so11651012wrb.0 for ; Thu, 19 Apr 2018 01:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=BOA45c5oL24r3srF1zt/G5GF3rLHJrLApFBffeEOa+4=; b=H5wuBgw6jMWHxgyzR3vxxaMOgs0C0eGYBNKv2bvrCm0zb+EWMBsn2V7GFN/V7Piwih mdXmNF7IP69ytEJUnrm9BFDgEoemR0j08paI1om2Oo+Idv43od3jsGA+boUBgNWm6UBJ n5bQc7FvDKTQDLKSDG/B5XHrXlrnU46ErIZdW2cwHk+AuHiJvL93ibjhRreVO0bKP4hN AUWvzvFgxbHZFnaOC696kb2BG1BwWf2PcUJsqk6p+L0+T2xQwzfcB45jizTCitVaLppd a/gyuJnZg1Kp96ahAC5briiywd7ti5IMtbKcwojE9zXilCW0GoaRbDKCwx8qzl+7RwGX uP3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=BOA45c5oL24r3srF1zt/G5GF3rLHJrLApFBffeEOa+4=; b=XZWsZ4FgebhdeOvC3MrhNSbzGCZ0Xx1FwT7KVy3Yq7cDga2e/bCcEULmgSc9/R4M1A AmtsoNU62xz9EsSluMeehqAL4S1ql90vvwCEjy1pGRvCUeE2PzoaXu8DOq9G/4xer6AO 5a7jvYAzJBXXpXbizliGp9VzZ36pHB5ZQhPDDE414veTk9KXiANP+6vf1nvytGnewwO2 P8EfuwJeNGsom25EW8D7RZQ9Om9Jg+ETmuM4Act+3HRBz4e9WCCtS13tSP/v8YVzupnu 6lAsNJ0+yTtkVDmMMttnnF1FxFvS53MKxYIP73qdKQiyvBX8mp/euvJKx7GOjhDGaOEr tUBQ== X-Gm-Message-State: ALQs6tAu8H16rse5ibbTVfCUkSr/s0JyKJDnUiPdw8pnRUFP8PDXRxtb PrAWOGKl7/X3XMStYYPgwcSy1+hQBts= X-Google-Smtp-Source: AIpwx4+I2zN4/TGDq2ftZKiBR8JGB+jNVB/6ZfUKmoTujLMtbEa712DxUf/kIG+QDV4A3F9NCemWnA== X-Received: by 10.28.220.137 with SMTP id t131mr4009151wmg.107.1524126681019; Thu, 19 Apr 2018 01:31:21 -0700 (PDT) Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id i138sm3400697wmf.22.2018.04.19.01.31.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 01:31:20 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_B1AC40C7-21A3-4FB3-BFC1-B00F85103EA2" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 19 Apr 2018 10:31:18 +0200 References: <5C447405-A453-41A3-8E58-02925FEB450D@sn3rd.com> <1524066159.11012.1342515920.44B1978A@webmail.messagingengine.com> To: "mls@ietf.org" In-Reply-To: Message-Id: <757B1710-5DC6-49AB-8473-B1F0E5FA9979@wire.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 08:31:29 -0000 --Apple-Mail=_B1AC40C7-21A3-4FB3-BFC1-B00F85103EA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks good to me, too! Raphael > On 19 Apr 2018, at 09:28, Emad Omara wrote: >=20 > LGTM >=20 >=20 > On Thu, Apr 19, 2018 at 7:33 AM Jon Millican > wrote: > Awesome, looks good to me. >=20 > Sent from my iPhone >=20 > On 18 Apr 2018, at 18:15, Cas Cremers > wrote: >=20 >> Dear all, >>=20 >> I am also happy with the revisions. Good to go! >>=20 >> Cas >>=20 >> On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, > wrote: >> +1 >>=20 >>=20 >> On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote: >>> LGTM. >>>=20 >>=20 >>> On 18 April 2018 at 16:18, Richard Barnes > wrote: >>=20 >>> Hey Sean, >>>=20 >>> This looks good to me. Ship it. >>>=20 >>> --Richard >>=20 >>> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner > wrote: >>=20 >>> Sorry I missed to minor edits from Jonathan Lennox didn=E2=80=99t = get copied over: >>>=20 >>> Messaging Layer Security (MLS) Charter (DRAFT) >>>=20 >>> Several Internet applications have a need for group key = establishment >>> and message protection protocols with the following properties: >>>=20 >>> o Message Confidentiality - Messages can only be read >>> by members of the group >>> o Message Integrity and Authentication - Each message >>> has been sent by an authenticated sender, and has >>> not been tampered with >>> o Membership Authentication - Each participant can verify >>> the set of members in the group >>> o Asynchronicity - Keys can be established without any >>> two participants being online at the same time >>> o Forward secrecy - Full compromise of a node at a point >>> in time does not reveal past messages sent within the group >>> o Post-compromise security - Full compromise of a node at a >>> point in time does not reveal future messages sent within the = group >>> o Scalability - Resource requirements have good scaling in the >>=20 >>> size of the group (preferably sub-linear) >>>=20 >>> Several widely-deployed applications have developed their own >>> protocols to meet these needs. While these protocols are similar, >>> no two are close enough to interoperate. As a result, each = application >>> vendor has had to maintain their own protocol stack and = independently >>> build trust in the quality of the protocol. The primary goal of this >>> working group is to develop a standard messaging security protocol >>> so that applications can share code, and so that there can be shared >>> validation of the protocol (as there has been with TLS 1.3).=20 >>>=20 >>> It is not a goal of this group to enable interoperability / = federation >>> between messaging applications beyond the key establishment, >>> authentication, and confidentiality services. Full interoperability >>> would require alignment at many different layers beyond security, >>> e.g., standard message transport and application semantics. The >>> focus of this work is to develop a messaging security layer that >>> different applications can adapt to their own needs. >>>=20 >>> While authentication is a key goal of this working group, it is not >>> the objective of this working group to develop new authentication >>> technologies. Rather, the security protocol developed by this >>> group will provide a way to leverage existing authentication >>> technologies to associate identities with keys used in the protocol, >>> just as TLS does with X.509. >>>=20 >>> In developing this protocol, we will draw on lessons learned from >>> several prior message-oriented security protocols, in addition to >>> the proprietary messaging security protocols deployed within >>> existing applications: >>>=20 >>> o S/MIME - https://tools.ietf.org/html/rfc5751 = >>> o OpenPGP - https://tools.ietf.org/html/rfc4880 = >>> o Off the Record - = https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html = >>=20 >>>=20 >>> o Signal - https://signal.org/docs/ = >>>=20 >>> The intent of this working group is to follow the pattern of >>> TLS 1.3, with specification, implementation, and verification >>> proceeding in parallel. By the time we arrive at RFC, we >>> hope to have several interoperable implementations as well >>=20 >>> as a thorough security analysis.. >>=20 >>>=20 >>> The specifications developed by this working group will be >>> based on pre-standardization implementation and deployment >>=20 >>> experience, generalizing the design described in: >>>=20 >>> o draft-omara-mls-architecture >>> o draft-barnes-mls-protocol >>>=20 >>> Note that consensus is required both for changes to the current >>> protocol mechanisms and retention of current mechanisms. In >>> particular, because something is in the initial document set does >>> not imply that there is consensus around the feature or around >>> how it is specified. >>>=20 >>> Milestones: >>> May 2018 - Initial working group documents for architecture and key = management >>> Sept 2018 - Initial working group document adopted for message = protection >>> Jan 2019 - Submit architecture document to IESG as Informational >>> Jun 2019 - Submit key management protocol to IESG as Proposed = Standard >>> Sept 2019 - Submit message protection protocol to IESG as Proposed = Standard >>>=20 >>> Cheers, >>>=20 >>> spt >>>=20 >>> > On Apr 13, 2018, at 14:09, Sean Turner > wrote: >>> >=20 >>> > All, >>> >=20 >>> > The charter tweaks made since the BOF include tweaking (and = reordering) some of the =E2=80=9Cproperty=E2=80=9D bullets: >>> > - added message confidentiality >>> > - message authentication changed to message integrity and = authentication >>> >=20 >>> > I know that Ben Schwartz mentioned that we should look at our = =E2=80=9Cfull compromise=E2=80=9D definition, but in reviewing it the = way it=E2=80=99s used in FS and PCS property bullets it looks okay to = me. But, maybe Ben can elaborate a bit. >>> >=20 >>> > Anyway at this point, here=E2=80=99s what we=E2=80=99re working = with: >>> >=20 >>> >=20 >>> > Messaging Layer Security (MLS) Charter (DRAFT) >>> >=20 >>> > Several Internet applications have a need for group key = establishment >>> > and message protection protocols with the following properties: >>> >=20 >>> > o Message Confidentiality - Messages can only be read >>> > by members of the group >>> > o Message Integrity and Authentication - Each message >>> > has been sent by an authenticated sender, and has >>> > not been tampered with >>> > o Membership Authentication - Each participant can verify >>> > the set of members in the group >>> > o Asynchronicity - Keys can be established without any >>> > two participants being online at the same time >>> > o Forward secrecy - Full compromise of a node at a point >>> > in time does not reveal past messages sent within the group >>> > o Post-compromise security - Full compromise of a node at a >>> > point in time does not reveal future messages sent within the = group >>> > o Scalability - Resource requirements that have good scaling in = the >>> > size of the group (preferably sub-linear) >>> >=20 >>> > Several widely-deployed applications have developed their own >>> > protocols to meet these needs.. While these protocols are similar, >>> > no two are close enough to interoperate. As a result, each = application >>> > vendor has had to maintain their own protocol stack and = independently >>> > build trust in the quality of the protocol. The primary goal of = this >>> > working group is to develop a standard messaging security protocol >>> > so that applications can share code, and so that there can be = shared >>> > validation of the protocol (as there has been with TLS 1.3).=20 >>> >=20 >>> > It is not a goal of this group to enable interoperability / = federation >>> > between messaging applications beyond the key establishment, >>> > authentication, and confidentiality services. Full = interoperability >>> > would require alignment at many different layers beyond security, >>> > e.g., standard message transport and application semantics. The >>> > focus of this work is to develop a messaging security layer that >>> > different applications can adapt to their own needs. >>> >=20 >>> > While authentication is a key goal of this working group, it is = not >>> > the objective of this working group to develop new authentication >>> > technologies. Rather, the security protocol developed by this >>> > group will provide a way to leverage existing authentication >>> > technologies to associate identities with keys used in the = protocol, >>> > just as TLS does with X.509. >>> >=20 >>> > In developing this protocol, we will draw on lessons learned from >>> > several prior message-oriented security protocols, in addition to >>> > the proprietary messaging security protocols deployed within >>> > existing applications: >>> >=20 >>> > o S/MIME - https://tools.ietf.org/html/rfc5751 = >>> > o OpenPGP - https://tools.ietf.org/html/rfc4880 = >>> > o Off the Record - = https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html = >>> > o Signal - https://signal.org/docs/ = >>> >=20 >>> > The intent of this working group is to follow the pattern of >>> > TLS 1.3, with specification, implementation, and verification >>> > proceeding in parallel. By the time we arrive at RFC, we >>> > hope to have several interoperable implementations as well >>> > as a thorough security analysis. >>> >=20 >>> > The specifications developed by this working group will be >>> > based on pre-standardization implementation and deployment >>> > experience, and generalizing the design described in: >>> >=20 >>> > o draft-omara-mls-architecture >>> > o draft-barnes-mls-protocol >>> >=20 >>> > Note that consensus is required both for changes to the current >>> > protocol mechanisms and retention of current mechanisms. In >>> > particular, because something is in the initial document set does >>> > not imply that there is consensus around the feature or around >>> > how it is specified. >>> >=20 >>> > Milestones: >>> > May 2018 - Initial working group documents for architecture and = key management >>> > Sept 2018 - Initial working group document adopted for message = protection >>> > Jan 2019 - Submit architecture document to IESG as Informational >>> > Jun 2019 - Submit key management protocol to IESG as Proposed = Standard >>> > Sept 2019 - Submit message protection protocol to IESG as Proposed = Standard >>> >=20 >>> > Cheers, >>> >=20 >>> > spt >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>=20 >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>>=20 >>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>=20 >>> https://www.ietf..org/mailman/listinfo/mls = >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >=20 >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvEq= Ma84Q&m=3DvLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=3DrCkO6bjAuzkicAcC= 9xQwtwWMKhvoGkeNcRvXkyLozng&e=3D = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --Apple-Mail=_B1AC40C7-21A3-4FB3-BFC1-B00F85103EA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Looks= good to me, too!

Raphael

On 19 Apr 2018, at 09:28, Emad = Omara <emadomara@google.com> wrote:

LGTM


On Thu, Apr 19, 2018 at 7:33 AM Jon Millican <jmillican@fb.com> = wrote:
Awesome, looks good to me.

Sent from = my iPhone

On 18 Apr 2018, at 18:15, Cas Cremers <cas.cremers@cs.ox.ac.uk> wrote:

Dear all,

I am also happy with the revisions. Good to go!

Cas

On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, <me@katriel.co.uk> wrote:
+1


On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote:
LGTM.

On 18 April 2018 at = 16:18, Richard Barnes <rlb@ipv.sx> wrote:
Hey Sean,

This looks good to me.  Ship it.

--Richard
On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner <sean@sn3rd.com> wrote:
Sorry I missed to = minor edits from Jonathan Lennox didn=E2=80=99t get copied over:

Messaging Layer Security (MLS) Charter (DRAFT)

Several Internet applications have a need for group key establishment
and message protection protocols with the following properties:

o Message Confidentiality - Messages can only be read
  by members of the group
o Message Integrity and Authentication - Each message
  has been sent by an authenticated sender, and has
  not been tampered with
o Membership Authentication - Each participant can verify
  the set of members in the group
o Asynchronicity - Keys can be established without any
  two participants being online at the same time
o Forward secrecy - Full compromise of a node at a point
  in time does not reveal past messages sent within the group
o Post-compromise security - Full compromise of a node at a
=   point in time does not reveal future messages sent within the = group
o Scalability - Resource requirements have good scaling in = the
  size of the = group (preferably sub-linear)

Several = widely-deployed applications have developed their own
protocols to meet = these needs. While these protocols are similar,
no two are close = enough to interoperate. As a result, each application
vendor has had to = maintain their own protocol stack and independently
build trust in the = quality of the protocol. The primary goal of this
working group is to = develop a standard messaging security protocol
so that applications = can share code, and so that there can be shared
validation of the = protocol (as there has been with TLS 1.3).

It is not a goal of = this group to enable interoperability / federation
between messaging = applications beyond the key establishment,
authentication, and = confidentiality services.  Full interoperability
would require = alignment at many different layers beyond security,
e.g., standard = message transport and application semantics.  The
focus of this work = is to develop a messaging security layer that
different = applications can adapt to their own needs.

While authentication = is a key goal of this working group, it is not
the objective of = this working group to develop new authentication
technologies.  = Rather, the security protocol developed by this
group will provide a = way to leverage existing authentication
technologies to = associate identities with keys used in the protocol,
just as TLS does = with X.509.

In developing this = protocol, we will draw on lessons learned from
several prior = message-oriented security protocols, in addition to
the proprietary = messaging security protocols deployed within
existing = applications:

o S/MIME - https://tools.ietf.org/html/rfc5751
o OpenPGP - https://tools.ietf.org/html/rfc4880
o Off the Record - = https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html

o Signal - https://signal.org/docs/

The intent of this = working group is to follow the pattern of
TLS 1.3, with = specification, implementation, and verification
proceeding in = parallel.  By the time we arrive at RFC, we
hope to have several = interoperable implementations as well
as a thorough = security analysis..

The specifications = developed by this working group will be
based on = pre-standardization implementation and deployment
experience, = generalizing the design described in:

o draft-omara-mls-architecture
o draft-barnes-mls-protocol

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In
= particular, because something is in the initial document set does
not imply that there is consensus around the feature or around
how it is specified.

Milestones:
May 2018 - Initial working group documents for architecture and key = management
Sept 2018 - Initial working group document adopted for message = protection
Jan 2019 - Submit architecture document to IESG as Informational
Jun 2019 - Submit key management protocol to IESG as Proposed = Standard
Sept 2019 - Submit message protection protocol to IESG as Proposed = Standard

Cheers,

spt

> On Apr 13, = 2018, at 14:09, Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> The charter = tweaks made since the BOF include tweaking (and reordering) some of the = =E2=80=9Cproperty=E2=80=9D bullets:
> - added message = confidentiality
> - message = authentication changed to message integrity and authentication
>
> I know that Ben = Schwartz mentioned that we should look at our =E2=80=9Cfull = compromise=E2=80=9D definition, but in reviewing it the way it=E2=80=99s = used in FS and PCS property bullets it looks okay to me.  But, = maybe Ben can elaborate a bit.
>
> Anyway at this = point, here=E2=80=99s what we=E2=80=99re working with:
>
>
> Messaging Layer = Security (MLS) Charter (DRAFT)
>
> Several = Internet applications have a need for group key establishment
> and message = protection protocols with the following properties:
>
> o Message = Confidentiality - Messages can only be read
>   by = members of the group
> o Message = Integrity and Authentication - Each message
>   has = been sent by an authenticated sender, and has
>   not = been tampered with
> o Membership = Authentication - Each participant can verify
>   the = set of members in the group
> o = Asynchronicity - Keys can be established without any
>   two = participants being online at the same time
> o Forward = secrecy - Full compromise of a node at a point
>   in = time does not reveal past messages sent within the group
> o = Post-compromise security - Full compromise of a node at a
>  =  point in time does not reveal future messages sent within the = group
> o Scalability - = Resource requirements that have good scaling in the
>  =  size of the group (preferably sub-linear)
>
> Several = widely-deployed applications have developed their own
> protocols to = meet these needs.. While these protocols are similar,
> no two are = close enough to interoperate. As a result, each application
=
> vendor has had = to maintain their own protocol stack and independently
> build trust in = the quality of the protocol. The primary goal of this
> working group = is to develop a standard messaging security protocol
> so that = applications can share code, and so that there can be shared
> validation of = the protocol (as there has been with TLS 1.3).
>
> It is not a = goal of this group to enable interoperability / federation
> between = messaging applications beyond the key establishment,
> authentication, = and confidentiality services.  Full interoperability
> would require = alignment at many different layers beyond security,
> e.g., standard = message transport and application semantics.  The
> focus of this = work is to develop a messaging security layer that
> different = applications can adapt to their own needs.
>
> While = authentication is a key goal of this working group, it is not
> the objective = of this working group to develop new authentication
> = technologies.  Rather, the security protocol developed by this
> group will = provide a way to leverage existing authentication
> technologies to = associate identities with keys used in the protocol,
> just as TLS = does with X.509.
>
> In developing = this protocol, we will draw on lessons learned from
> several prior = message-oriented security protocols, in addition to
> the proprietary = messaging security protocols deployed within
> existing = applications:
>
> o S/MIME - https://tools.ietf.org/html/rfc5751
> o OpenPGP - https://tools.ietf.org/html/rfc4880
> o Off the = Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
> o Signal - https://signal.org/docs/
>
> The intent of = this working group is to follow the pattern of
> TLS 1.3, with = specification, implementation, and verification
> proceeding in = parallel.  By the time we arrive at RFC, we
> hope to have = several interoperable implementations as well
> as a thorough = security analysis.
>
> The = specifications developed by this working group will be
> based on = pre-standardization implementation and deployment
> experience, and = generalizing the design described in:
>
> o = draft-omara-mls-architecture
> o = draft-barnes-mls-protocol
>
> Note that = consensus is required both for changes to the current
> protocol = mechanisms and retention of current mechanisms. In
> particular, = because something is in the initial document set does
> not imply that = there is consensus around the feature or around
> how it is = specified.
>
> Milestones:
> May 2018 - = Initial working group documents for architecture and key management
> Sept 2018 - = Initial working group document adopted for message protection
> Jan 2019 - = Submit architecture document to IESG as Informational
> Jun 2019 - = Submit key management protocol to IESG as Proposed Standard
=
> Sept 2019 - = Submit message protection protocol to IESG as Proposed Standard
>
> Cheers,
>
> spt

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf..org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
MLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&am= p;r=3DM0CVEJydBVUX_bvEqMa84Q&m=3DvLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5= T-sm7U&s=3DrCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e=3D
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS = mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

= --Apple-Mail=_B1AC40C7-21A3-4FB3-BFC1-B00F85103EA2-- From nobody Thu Apr 19 01:36:08 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91B126BF7 for ; Thu, 19 Apr 2018 01:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rub.de 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 pQtbEFCykE-r for ; Thu, 19 Apr 2018 01:36:02 -0700 (PDT) Received: from out1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:3595]) (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 8C26F126CBF for ; Thu, 19 Apr 2018 01:36:02 -0700 (PDT) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 40RXPt0GDrz4y2F for ; Thu, 19 Apr 2018 10:36:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rub.de; s=mail-2017; t=1524126962; bh=+gdV8TZHjkG5SmSoeeBokEJYslODfkAbWOkfEoPI8zs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YBWGAm6ItYWjoG1KWJpTzPHi1rvjOWMghN5fLoI4H/3rM+D80+GxOvq5QNwdiYtH8 mZVg8TwTbGilX5w6fS07ymr0QKcoD5C+mv+l9NAjlvO+PRfRyka9WjAQy29c3Iwq/r ZMnJinulD7hhj9RxgdNuIs5yda1xtJs1AzbH6ay0= Received: from out1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 40RXPs6dXMz4yg3 for ; Thu, 19 Apr 2018 10:36:01 +0200 (CEST) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 40RXPs6PRFz4yfK for ; Thu, 19 Apr 2018 10:36:01 +0200 (CEST) Received: from [192.168.1.156] (unknown [134.147.203.251]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 40RXPq4k0VzybJ for ; Thu, 19 Apr 2018 10:35:59 +0200 (CEST) To: mls@ietf.org References: From: =?UTF-8?Q?Paul_R=c3=b6sler?= Openpgp: preference=signencrypt Autocrypt: addr=paul.roesler@rub.de; prefer-encrypt=mutual; keydata= xsJuBFMPNo4RCACsEL23jO1k25wZhdphKuPdmEnxvjbtZavn1ZkALMxWJ4bYHPxNkpZWCT9h v0ZizDoosjlIvh0lK0nZgK0MLwjG/swrG/qUoZPIxStbXSVZPPwSdTaa+nzN0HD2y30zDExP 9WtchiEnGPB8WLCjkx5qscrBZV+PzI5akdK2CGBDthVvYzu4oLMZ89akJfM82ap9fGf0pfMh 4Qj4zIH6Vt6PIDn/r3d1GNW00RlEaq+MerAp3WkO+BwZ/2yCM+WJFG4w8tI3p+CjUlZehU2o WBxAmaLLHK3HOrCxiyGWZtIXy5plSfBjDomrlnlIiaDiC0N+MleHF8+IqxAo0XKySXn3AQDm UVBV0DpdIxm8dk2BCT5pMdnZFxzoBbSt57Tv9htwcwgAqpCy5Fhfcm5fVdhkeuaX86izCPfn 1k6FDt/3VUZ7lwcLJL9qYp1treUptfrUJ/DOeZN5LAyULj2Aijjy2Tni3RrDR9+1NvLTla4v bJpndEWI0nof1l8za+sfeQn8YnSylZLFt/Blx3MAe0MnNi9ZbGk50fdKjNsBwCwcZP/1Gyen s05rk2aaL07n5guCz/0bmlQFANCyi3lH+EcHJ0I4wYriBA4xJ3wDJmrCtjhsAtHNnc6pqvgE S2h2J7gAGa7A+ktFJhAxmVSx02GzakjNenx/SWMT2zlIZ/tu1T3wdX3SghUvX62p37FXPObF EbaEJZc9j4jUqnaJHbj/q717Gwf/S3mVyiMaIVzfbxmngGVfaf89vHRh7sWvkt9+TarR7Xen M2Bwi9wKgJ6pshkAnIe6VCGx4+JNH5SUiaxVr6TyrK9GcDkfCEwcVGwDBmeKdtv5Psb2Ho6t tTIWPwj/eQAJn283X18izF1xYYDFSct835R3hG6baP1FJZmMSm+CxV8C+uZXB/Yom/p4NblJ ujLJPGVampAZYs3ZVLrQBuxrXhGrDimFY9TLgO3ZN4gN4gQ3OvvBzmagwGMJdszTaRNE3JGE /qzvlvIs3KTLpQzybxZWwl7SO8b7A+i6+Yp9uN6thrpX7/TdnKcvnMezNYMRjuXvRGmaZ7c2 thgDF83fY80jUGF1bCBSw7ZzbGVyIDxtYWlsQHJvZXNsZXItcGF1bC5kZT7CfgQTEQgAJgIb IwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheABQJTDzbTAhkBAAoJEBbS1xKcazdGVrAA/3lK QI/T1aM6i6KysCui1/fluId0YmRRqypKMA+XAz2gAP4tLC5YbgGw9O9nMTivNqqPiLthcl/j SqJFkN9wvZOvIs7BTQRTDzaOEAgAlESVhuAL+WnQd/2DG4VxkkozWwDayzdpvP6L3agcf6bx ftRHlYPFGh6Ks5kwjTlo3+W9dX0PzM6rAaeTh1hJs1z793p/SKI6C184G/ReGSxZf4/sX1OL jpsrqyiCsWxth8wv8ha9hNLNInF3jA6fpJna7VVh4pE05Elc5BIkX+gXyGd4LtMUd+r3oEje b6hfHxdM0aOwv/ekJqY5o0MZdNjQ6bJ8o7YrKfp1mLG6dYXGa9z3nEmjbXJ/74YgZSpTtGg1 Do+uaOCU4AvD3uBvB85PWyIhasCoOniNh762HBhDDGu9GyRGXnQBIz/+gQNjuXTzUvACZ2Ah QscDlZ2qnwADBwgAhgobq3ALUCG7DeLpEK9uwZJMt9rGJfRwlj5YafXb66kCRuLOOgKzSjy+ 7f5OYQei+byxYc0+/JKTxhaIReLDP/iafm/E2b6n0kKrznrdCu/EwJ+q5MtyrLlUHeY7NEVj VZhYw9zaL6J5Ed4EJfbOYMzovQPkJ3rDLCqs/phYpg1Yd1+qGo1ODjLXC8ThBfvoSL/pLhvf HxLyPQATpuT4rVhNa3RsMceQ4jNVKL5SvJwuomrWgFUyteRQLt12M6DjmaUeTXHSntfqjQVy 8+1rC/k1UhV35yuGUMbDmPL5dcGWYvYXRqTBKC39NMXtICM8zTBTTlGhMp2Zcz+lka7LR8Jh BBgRCAAJBQJTDzaOAhsMAAoJEBbS1xKcazdGw7MBANgKvPttJHvY4OgwW4ieVk30QFrIMtKh DPr0iJcobzajAP9BuJfwsGAR/zE0lByRtCvJymNYhst5Hf9FitY4nBJ2Rg== Message-ID: Date: Thu, 19 Apr 2018 10:35:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: Subject: Re: [MLS] Revised MLS charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 08:36:06 -0000 LGTM! On 19.04.2018 10:31, Raphael Robert wrote: > > Looks good to me, too! > > Raphael > >> On 19 Apr 2018, at 09:28, Emad Omara wrote: >> >> LGTM >> >> >> On Thu, Apr 19, 2018 at 7:33 AM Jon Millican > wrote: >> Awesome, looks good to me. >> >> Sent from my iPhone >> >> On 18 Apr 2018, at 18:15, Cas Cremers > wrote: >> >>> Dear all, >>> >>> I am also happy with the revisions. Good to go! >>> >>> Cas >>> >>> On Wed, 18 Apr 2018, 16:42 Katriel Cohn-Gordon, > wrote: >>> +1 >>> >>> >>> On Wed, 18 Apr 2018, at 4:39 PM, Dave Cridland wrote: >>>> LGTM. >>>> >>> >>>> On 18 April 2018 at 16:18, Richard Barnes > wrote: >>> >>>> Hey Sean, >>>> >>>> This looks good to me. Ship it. >>>> >>>> --Richard >>> >>>> On Fri, Apr 13, 2018 at 2:52 PM, Sean Turner > wrote: >>> >>>> Sorry I missed to minor edits from Jonathan Lennox didn?t get copied over: >>>> >>>> Messaging Layer Security (MLS) Charter (DRAFT) >>>> >>>> Several Internet applications have a need for group key establishment >>>> and message protection protocols with the following properties: >>>> >>>> o Message Confidentiality - Messages can only be read >>>> by members of the group >>>> o Message Integrity and Authentication - Each message >>>> has been sent by an authenticated sender, and has >>>> not been tampered with >>>> o Membership Authentication - Each participant can verify >>>> the set of members in the group >>>> o Asynchronicity - Keys can be established without any >>>> two participants being online at the same time >>>> o Forward secrecy - Full compromise of a node at a point >>>> in time does not reveal past messages sent within the group >>>> o Post-compromise security - Full compromise of a node at a >>>> point in time does not reveal future messages sent within the group >>>> o Scalability - Resource requirements have good scaling in the >>> >>>> size of the group (preferably sub-linear) >>>> >>>> Several widely-deployed applications have developed their own >>>> protocols to meet these needs. While these protocols are similar, >>>> no two are close enough to interoperate. As a result, each application >>>> vendor has had to maintain their own protocol stack and independently >>>> build trust in the quality of the protocol. The primary goal of this >>>> working group is to develop a standard messaging security protocol >>>> so that applications can share code, and so that there can be shared >>>> validation of the protocol (as there has been with TLS 1.3). >>>> >>>> It is not a goal of this group to enable interoperability / federation >>>> between messaging applications beyond the key establishment, >>>> authentication, and confidentiality services. Full interoperability >>>> would require alignment at many different layers beyond security, >>>> e.g., standard message transport and application semantics. The >>>> focus of this work is to develop a messaging security layer that >>>> different applications can adapt to their own needs. >>>> >>>> While authentication is a key goal of this working group, it is not >>>> the objective of this working group to develop new authentication >>>> technologies. Rather, the security protocol developed by this >>>> group will provide a way to leverage existing authentication >>>> technologies to associate identities with keys used in the protocol, >>>> just as TLS does with X.509. >>>> >>>> In developing this protocol, we will draw on lessons learned from >>>> several prior message-oriented security protocols, in addition to >>>> the proprietary messaging security protocols deployed within >>>> existing applications: >>>> >>>> o S/MIME - https://tools.ietf.org/html/rfc5751 >>>> o OpenPGP - https://tools.ietf.org/html/rfc4880 >>>> o Off the Record - https://otr.cypherpunks...ca/Protocol-v3-4.1.1.html >>> >>>> >>>> o Signal - https://signal.org/docs/ >>>> >>>> The intent of this working group is to follow the pattern of >>>> TLS 1.3, with specification, implementation, and verification >>>> proceeding in parallel. By the time we arrive at RFC, we >>>> hope to have several interoperable implementations as well >>> >>>> as a thorough security analysis.. >>> >>>> >>>> The specifications developed by this working group will be >>>> based on pre-standardization implementation and deployment >>> >>>> experience, generalizing the design described in: >>>> >>>> o draft-omara-mls-architecture >>>> o draft-barnes-mls-protocol >>>> >>>> Note that consensus is required both for changes to the current >>>> protocol mechanisms and retention of current mechanisms. In >>>> particular, because something is in the initial document set does >>>> not imply that there is consensus around the feature or around >>>> how it is specified. >>>> >>>> Milestones: >>>> May 2018 - Initial working group documents for architecture and key management >>>> Sept 2018 - Initial working group document adopted for message protection >>>> Jan 2019 - Submit architecture document to IESG as Informational >>>> Jun 2019 - Submit key management protocol to IESG as Proposed Standard >>>> Sept 2019 - Submit message protection protocol to IESG as Proposed Standard >>>> >>>> Cheers, >>>> >>>> spt >>>> >>>>> On Apr 13, 2018, at 14:09, Sean Turner > wrote: >>>>> >>>>> All, >>>>> >>>>> The charter tweaks made since the BOF include tweaking (and reordering) some of the ?property? bullets: >>>>> - added message confidentiality >>>>> - message authentication changed to message integrity and authentication >>>>> >>>>> I know that Ben Schwartz mentioned that we should look at our ?full compromise? definition, but in reviewing it the way it?s used in FS and PCS property bullets it looks okay to me. But, maybe Ben can elaborate a bit. >>>>> >>>>> Anyway at this point, here?s what we?re working with: >>>>> >>>>> >>>>> Messaging Layer Security (MLS) Charter (DRAFT) >>>>> >>>>> Several Internet applications have a need for group key establishment >>>>> and message protection protocols with the following properties: >>>>> >>>>> o Message Confidentiality - Messages can only be read >>>>> by members of the group >>>>> o Message Integrity and Authentication - Each message >>>>> has been sent by an authenticated sender, and has >>>>> not been tampered with >>>>> o Membership Authentication - Each participant can verify >>>>> the set of members in the group >>>>> o Asynchronicity - Keys can be established without any >>>>> two participants being online at the same time >>>>> o Forward secrecy - Full compromise of a node at a point >>>>> in time does not reveal past messages sent within the group >>>>> o Post-compromise security - Full compromise of a node at a >>>>> point in time does not reveal future messages sent within the group >>>>> o Scalability - Resource requirements that have good scaling in the >>>>> size of the group (preferably sub-linear) >>>>> >>>>> Several widely-deployed applications have developed their own >>>>> protocols to meet these needs.. While these protocols are similar, >>>>> no two are close enough to interoperate. As a result, each application >>>>> vendor has had to maintain their own protocol stack and independently >>>>> build trust in the quality of the protocol. The primary goal of this >>>>> working group is to develop a standard messaging security protocol >>>>> so that applications can share code, and so that there can be shared >>>>> validation of the protocol (as there has been with TLS 1.3). >>>>> >>>>> It is not a goal of this group to enable interoperability / federation >>>>> between messaging applications beyond the key establishment, >>>>> authentication, and confidentiality services. Full interoperability >>>>> would require alignment at many different layers beyond security, >>>>> e.g., standard message transport and application semantics. The >>>>> focus of this work is to develop a messaging security layer that >>>>> different applications can adapt to their own needs. >>>>> >>>>> While authentication is a key goal of this working group, it is not >>>>> the objective of this working group to develop new authentication >>>>> technologies. Rather, the security protocol developed by this >>>>> group will provide a way to leverage existing authentication >>>>> technologies to associate identities with keys used in the protocol, >>>>> just as TLS does with X.509. >>>>> >>>>> In developing this protocol, we will draw on lessons learned from >>>>> several prior message-oriented security protocols, in addition to >>>>> the proprietary messaging security protocols deployed within >>>>> existing applications: >>>>> >>>>> o S/MIME - https://tools.ietf.org/html/rfc5751 >>>>> o OpenPGP - https://tools.ietf.org/html/rfc4880 >>>>> o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html >>>>> o Signal - https://signal.org/docs/ >>>>> >>>>> The intent of this working group is to follow the pattern of >>>>> TLS 1.3, with specification, implementation, and verification >>>>> proceeding in parallel. By the time we arrive at RFC, we >>>>> hope to have several interoperable implementations as well >>>>> as a thorough security analysis. >>>>> >>>>> The specifications developed by this working group will be >>>>> based on pre-standardization implementation and deployment >>>>> experience, and generalizing the design described in: >>>>> >>>>> o draft-omara-mls-architecture >>>>> o draft-barnes-mls-protocol >>>>> >>>>> Note that consensus is required both for changes to the current >>>>> protocol mechanisms and retention of current mechanisms. In >>>>> particular, because something is in the initial document set does >>>>> not imply that there is consensus around the feature or around >>>>> how it is specified. >>>>> >>>>> Milestones: >>>>> May 2018 - Initial working group documents for architecture and key management >>>>> Sept 2018 - Initial working group document adopted for message protection >>>>> Jan 2019 - Submit architecture document to IESG as Informational >>>>> Jun 2019 - Submit key management protocol to IESG as Proposed Standard >>>>> Sept 2019 - Submit message protection protocol to IESG as Proposed Standard >>>>> >>>>> Cheers, >>>>> >>>>> spt >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>> >>>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> >>> >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>> >>>> https://www.ietf..org/mailman/listinfo/mls >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >> >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=vLw7yR8_BHETHOm3fcZejeAr3aBZpvg3HL8G5T-sm7U&s=rCkO6bjAuzkicAcC9xQwtwWMKhvoGkeNcRvXkyLozng&e= >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > ------------------------------ > > End of MLS Digest, Vol 3, Issue 10 > ********************************** >