From nobody Wed Sep 11 14:46:51 2019 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9334D120090; Wed, 11 Sep 2019 14:46:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <156823840256.13250.16714879767782869655@ietfa.amsl.com> Date: Wed, 11 Sep 2019 14:46:42 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-federation-00.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 21:46:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Federation Authors : Emad Omara Raphael Robert Filename : draft-ietf-mls-federation-00.txt Pages : 8 Date : 2019-09-11 Abstract: This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS implementations can interoperate by defining the message format for user key retrieval. The document also describes some use cases where federation could be useful. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-federation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-federation-00 https://datatracker.ietf.org/doc/html/draft-ietf-mls-federation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 13 07:12:06 2019 Return-Path: X-Original-To: mls@ietf.org Delivered-To: mls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0315C12083C; Fri, 13 Sep 2019 07:11:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: mls@ietf.org Message-ID: <156838391491.31902.18066422867341894579@ietfa.amsl.com> Date: Fri, 13 Sep 2019 07:11:55 -0700 Archived-At: Subject: [MLS] I-D Action: draft-ietf-mls-architecture-03.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 14:11:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Layer Security WG of the IETF. Title : The Messaging Layer Security (MLS) Architecture Authors : Emad Omara Benjamin Beurdouche Eric Rescorla Srinivas Inguva Albert Kwon Alan Duric Filename : draft-ietf-mls-architecture-03.txt Pages : 16 Date : 2019-09-13 Abstract: This document describes the architecture and requirements for the Messaging Layer Security (MLS) protocol. MLS provides a security layer for group messaging applications with from two to a large number of clients. It is meant to protect against eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mls-architecture-03 https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mls-architecture-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 16 13:55:02 2019 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 3FB1C1202A0 for ; Mon, 16 Sep 2019 13:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17 X-Spam-Level: X-Spam-Status: No, score=-17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 bKECZbFuaSbE for ; Mon, 16 Sep 2019 13:54:50 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 39D39120845 for ; Mon, 16 Sep 2019 13:54:50 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id n7so1604693qtb.6 for ; Mon, 16 Sep 2019 13:54:50 -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=LNGGZH60P51ntW0NjkZw3tLqR2jbzIlwiO8BXzxpDq8=; b=Qldlx6ATWNj4WyFzanWGGiRV8VeY9dELLCzgBc1oDYwLRQb3jTm4j/G3KdQz9XWftl 1z2ga2gKXOf/wO3/+guetc0w+ZRNN3xv/8GvIjcAGmJD7FGDL1gP0cEptLnu9poWqIff t7m6HjGxBF8r8uyA/r8+bkzG57u1Lb10iHwc1LGwFwZbbYfKn0EVYwFvtjoZkFwJwFKE mXlIGDv4Q89qxc4h6IclkYxU1jY+9uBYCzTrOwY5oKYRxVF72NGf5iiGK9TMUcy08ACz /gjOl1Pjbkwdw+r+DETs4HBD6n37nV0l5wVF4UE4e72QRu7rp5+27WN9hrRp2jXfQa/J kbkw== 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=LNGGZH60P51ntW0NjkZw3tLqR2jbzIlwiO8BXzxpDq8=; b=q2llxI+OIawxK3qpXhRg499rpHiZQ2NyAygIb4jaeGBC20IjS+Y8GfE3MOxXgs9Go0 rTC8R0lkJtVH5kEvK3f3qTPWqq0f8ifim1dzJ9KC7AEAOJSZggxc18ZGgJIMBiNzD7ib ovk9FFNPbFlRZ4Dpz/LBCP7stYlrSp90Axl/8GGCiT+om5jBh7e5sJh+0Yi3Lmg8H8UK 2G3ENud3y9Fy+ssoBL8fNIye3ZluSsgWdx94R8lSaA09nEPrZ6cj+Qf9l3exqRVYwJQc zkWmUS9GsxAyiC5xuKss85f8LvIb1MStxp7IbpiJ8iVIm5UgNcHltHVJHqni4P+B3lBK DicA== X-Gm-Message-State: APjAAAUMvNuDn6X4OM4b4jcxq5zfEwvKfBF8uJMh1Wvm500bGP3jR39D nAV49WfI2FPsGxp/UCt3Jcj+LaGoL426WqhUCtn7MQ== X-Google-Smtp-Source: APXvYqzwdenwfyRqe7l7QRTIUzrtACYopaHLcSbKICNbvMMY5I753zYVxeQJa40FY7/mqBfe0TTWRYX6OELcR7HqGC0= X-Received: by 2002:ac8:73cf:: with SMTP id v15mr341861qtp.131.1568667288760; Mon, 16 Sep 2019 13:54:48 -0700 (PDT) MIME-Version: 1.0 References: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org> In-Reply-To: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org> From: Peter Slatala Date: Mon, 16 Sep 2019 13:54:22 -0700 Message-ID: To: Jon Callas Cc: Messaging Layer Security WG , Benjamin Beurdouche Content-Type: multipart/alternative; boundary="00000000000084f3ec0592b1d00c" Archived-At: Subject: Re: [MLS] AEAD data in messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 20:55:00 -0000 --00000000000084f3ec0592b1d00c Content-Type: text/plain; charset="UTF-8" Thanks Benjamin, Jon & Jeff for the discussion so far. I have wrote made a tiny proposal ( https://github.com/mlswg/mls-protocol/pull/208 ) to add AAD. It doesn't look like the spec is the place to discuss possible applications or tradeoffs, so we can do it in a pull request :) Let me know what's the best way to proceed here (discussion in the pull request? interim? continuing in the email thread?) Looking forward to your comments and suggestions, Peter On Sat, Aug 17, 2019 at 4:58 PM Jon Callas wrote: > > > On Aug 15, 2019, at 9:03 AM, Peter Slatala wrote: > > Thanks Jon! This is a lot of good feedback. As you mentioned, a lot of > this AAD can be addressed by a separate edge-to-service key; what we > optimize for here is message overhead. Overhead is less of a concern for > messaging (unlike for real-time media), so it may be fine to have TLS + > edge-to-service + encrypted message itself. The quirk is that some of the > metadata would then have to be repeated in both delivery service encrypted > message & e2ee encrypted message, which is what I wanted to optimize. By > putting the info in AAD & using TLS we essentially save overhead (from > duplicating data, and from extra encryption overhead to the server). > > I'll think about it more and see if I can come up with a reasonable > proposal, but I am afraid I won't be able to come up with a solution that > will address all of your concerns. > > > Come up with the proposal. > > In general, I'm not opposed to features. Features are good and features > are bad. Too few makes a system brittle, too many makes it hard to assess > overall security and might introduce problems. > > Putting in a feature ought to do one of two things: enable something that > is reasonable for someone to do, but no one is doing it yet (future > expansion) or to head off a potential problem. > > On its surface, putting in AEAD doesn't sound bad, but we should avoid a > situation where when Alice sends a message to Bob, there's something in > there that is not directly relevant to that. A server in the middle ideally > is just routing cipher text that is interpreted when Bob gets it, or is a > message from Alice to the server. You gave lots of examples of things Alice > might want to say to the server. I think it's a bad idea to conflate those > into a single message. I also think it's a bad idea to have plaintext > metadata in a message. A server can be compromised in subtle ways, like > exceptional access, and making the protocol access-ready with metadata > seems suboptimal. > > Without an obvious upside to an AEAD message -- meaning something that the > AAD does that can't be done another way, my intuition is to leave it out. > We have scenarios that are downside, with no obvious upside, so the risk > calculus says to leave it out in my thinking. > > Obviously, with a use case for the AAD, that changes. That means > describing something where the AAD permits us to do X that we couldn't do > any other way. > > > > Actually the header encryption exists to protect MLS metadata from the > delivery service, so ideally most systems should deploy it. > When you say header encryption, what exactly do you mean? (I don't believe > draft mentions this). > > > I searched through this thread, and I haven't found where I said "header > encryption." The first mention is from Jeff Burdges; perhaps he's the best > one to define it. > > Jon > > > --00000000000084f3ec0592b1d00c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Benjamin, Jon & Jeff for the discussion so far.=

I have wrote made a tiny proposal (=C2=A0https://github.com/mlswg/mls-p= rotocol/pull/208=C2=A0) to add AAD. It doesn't look like the spec i= s the place to discuss possible applications or tradeoffs, so we can do it = in a pull request :)

Let me know what's the be= st way to proceed here (discussion in the pull request? interim? continuing= in the email thread?)

Looking forward to your com= ments and suggestions,
Peter

On Sat, Aug 17, 2019 at 4:58 PM= Jon Callas <jon@callas.org> wr= ote:


On Aug 15, 2019, at 9:03 AM, Peter Slatala <psla+mls@google.com> wrote:

<= div>
Thanks Jon! This is a lot of good fee= dback. As you mentioned, a lot of this AAD can be addressed by a separate e= dge-to-service key; what we optimize for here is message overhead. Overhead= is less of a concern for messaging (unlike for real-time media), so it may= be fine to have TLS=C2=A0+ edge-to-service=C2=A0+ encrypted messa= ge itself. The quirk is that some of the metadata would then have to be rep= eated in both delivery service encrypted message & e2ee encrypted messa= ge, which is what I wanted to optimize. By putting the info in AAD & us= ing TLS we essentially save overhead (from duplicating data, and from extra= encryption overhead to the server).

I= 'll think about it more and see if I can come up with a reasonable prop= osal, but I am afraid I won't be able to come up with a solution that w= ill address all of your concerns.

Come up with the proposal.=C2=A0

In gener= al, I'm not opposed to features. Features are good and features are bad= . Too few makes a system brittle, too many makes it hard to assess overall = security and might introduce problems.

Putting in = a feature ought to do one of two things: enable something that is reasonabl= e for someone to do, but no one is doing it yet (future expansion) or to he= ad off a potential problem.

On its surface, puttin= g in AEAD doesn't sound bad, but we should avoid a situation where when= Alice sends a message to Bob, there's something in there that is not d= irectly relevant to that. A server in the middle ideally is just routing ci= pher text that is interpreted when Bob gets it, or is a message from Alice = to the server. You gave lots of examples of things Alice might want to say = to the server. I think it's a bad idea to conflate those into a single = message. I also think it's a bad idea to have plaintext metadata in a m= essage. A server can be compromised in subtle ways, like exceptional access= , and making the protocol access-ready with metadata seems suboptimal.

Without an obvious upside to an AEAD message -- meanin= g something that the AAD does that can't be done another way, my intuit= ion is to leave it out. We have scenarios that are downside, with no obviou= s upside, so the risk calculus says to leave it out in my thinking.

Obviously, with a use case for the AAD, that changes. Tha= t means describing something where the AAD permits us to do X that we could= n't do any other way.


> Actually the header encryption exists to = protect=C2=A0MLS=C2=A0metadata from the delivery service, so i= deally most systems should deploy it.
When you say header encrypt= ion, what exactly do you mean? (I don't believe draft mentions this).

I searched through this thread,= and I haven't found where I said "header encryption." The fi= rst mention is from Jeff Burdges; perhaps he's the best one to define i= t.

Jo= n


--00000000000084f3ec0592b1d00c-- From nobody Wed Sep 18 15:16:27 2019 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 CE49D1200C7 for ; Wed, 18 Sep 2019 15:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 HeW-xMuSxjUw for ; Wed, 18 Sep 2019 15:16:22 -0700 (PDT) Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) (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 B1FF012002F for ; Wed, 18 Sep 2019 15:16:22 -0700 (PDT) Received: by mail-ot1-x341.google.com with SMTP id 21so1270087otj.11 for ; Wed, 18 Sep 2019 15:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NGh4ErRkXdM85Q5080vwzWYpO5wJxiGVBrc0zP0zV98=; b=UJ6+uHWimrTgiVZFd6GF0g9wVXO0nLJMmLfjW0Eo4D8UhOYkFBzWKmvofOr0yd7MQm 0IY+0XFnE/kL5Z5dylZZoLS6fc6ADy+TQvxBemJGQz3KG6K6hF+2yyCLPkW4D8ucb6LL npsFxinQp9peDT/n9svIIetT8nruwxf0l5MaWeoMHx8fPBfFgwcjvxgYTcX6wLKNZqOG m2ebTLET5iZOd+MbQ6tbEOVcKW7YalGBGfucJ9tEzwJ5gpP1gu9bC1ufYQ4She64xPw6 FDxZ69eplitgrTi2maHZFxK4HNUbhfObU8LnZtDXZaDiBgk+waRXUz4Y+d/DhQuBPVWT ZZkw== 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; bh=NGh4ErRkXdM85Q5080vwzWYpO5wJxiGVBrc0zP0zV98=; b=o0548b2JhmBVeO8A6A4jwJk7R9Y3H4fyiSv6PI1fvN1bd/xOA1ahn7+sLVJhSoWuBK tynA9AnUsvk3aBLg/tmmwTktkfHPTm/koIOtIngRqBvHnIrQicYlwE0TWn2k/LjEBPeP XqQ6fEzaAZ/6vgiHqOMLvVhYNEwHNnV4Tz04vVHN0vl9IBMgOIKyMNcnWfFAsu1TnZBi euWcBmYkgB+MiOOTTZH80J4lJrq2quOGRaZdgCU2bAr8JNOiBflbQHSOjhsgnfxKsShT SYZB2XQeNGxGPBBt8tsV4Zh5xrrwIIjhckmXATxD4nwOUfa1EjB30yaYaGfJuM+ngDvy 9vZg== X-Gm-Message-State: APjAAAWX5FHBIVO1feiPftKjLRXcg0o2ajtv2P14iyIzIkGL9/+1YYPc fU7Tx1rtfZiozmx+nwL/8KodH0yknxEfqbHyXejaUsvzX+Fa6A== X-Google-Smtp-Source: APXvYqwP59xJGHV+SCITxtrToiVon1TZ+UkVIES7lpUO+j+rh64UwBxOyTjXvRZ1b6Fe3c0VvJsx2CW5V2jnqTxMbyM= X-Received: by 2002:a9d:6d82:: with SMTP id x2mr1566720otp.42.1568844981503; Wed, 18 Sep 2019 15:16:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Wed, 18 Sep 2019 18:16:08 -0400 Message-ID: To: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="000000000000d4a90e0592db2f44" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 22:16:26 -0000 --000000000000d4a90e0592db2f44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've written up a PR that implements this proposal: https://github.com/mlswg/mls-protocol/pull/209 Please take a look; there's plenty in there to disagree about, and several OPEN ISSUEs. I would like to have this landed in the next week or so, so that we can rebase some other PRs on it (e.g., non-destructive add) and publish a new draft for the interim. Thanks, --Richard On Thu, Aug 22, 2019 at 6:16 PM Richard Barnes wrote: > Hey all, > > I=E2=80=99d like to pose a question to the group of whether we should do > =E2=80=9Claziness=E2=80=9D or not. The complete form will be long, but = the short version > is: Do we care enough about DH overhead and server-initiated operations t= o > do a pretty significant refactor and possibly add some complexity to the > protocol? > > I would like to get a go/no-go on this idea before writing a PR, since > it's going to be a big PR. And it would be helpful to make that decision > in the next week or two, so that we can get the edits done and a new > version out a bit in advance of the interim. So let's get this party > started! > > # Objectives > > The overall goal is to meet two objectives: > > 1. Not requiring DH operations in groups where no messaging is happening > 2. Allow some flavor of server-initiated Add and Remove > > The first of these objectives was raised by Raphael some time ago; see hi= s > presentation at the January interim for more details [1]. The second has > been a long-outstanding feature request, from Facebook and Cisco, among > others. > > The useful insight is that both of these require deferred operations. In > the first case, you want to defer DH operations until someone wants to se= nd > a message. In the second case, you might have the server propose an > operation that it can=E2=80=99t do, so that the execution of the operatio= n is > deferred until someone in the group does it. > > # Proposal > > The proposal here is to refactor the protocol from =E2=80=9Cimmediate mod= e=E2=80=9D to > =E2=80=9Cdeferred mode=E2=80=9D. None of the underlying tree math change= s, just how we > talk about it. > > * Add, Remove, and Update become =E2=80=9CProposals=E2=80=9D that describ= e an operation, > rather than carrying the information to accomplish the information > immediately > * Add =3D =E2=80=9CPlease add ${ClientInitKey}=E2=80=9D > * Update =3D =E2=80=9CPlease replace the leaf at ${index} with ${key}= and blank > its direct path=E2=80=9D > * Remove =3D =E2=80=9CPlease remove the member at ${index} > * Each epoch contains a set of proposals, followed by a Commit message > * None of the proposed changes take effect until the Commit message > * If there are outstanding proposals, you SHOULD send a Commit before > sending a message > * A Commit message contains: > * A description of which proposals were applied and how > * In particular, the committer chooses the positions where new member= s > are added > * A direct path that KEMs new entropy to the group (basically an > update from the Committer) > * The committer also generates Welcome messages for any new participants > * With handshake encryption, the Welcome just needs to have the key > for the Commit > * The Commit should commit to the state of the tree after the > proposals are executed (just like handshake messages do today) > * ... so the new joiner doesn't need to see the proposals, just the > Commit > > # Observations > > * In the framework above, there's no need to synchronize proposals, just > Commits > * If the Commit includes the proposals by value or hash, then we can just > run the transcript over the Commit messages, and the proposals will be > included transitively > * Note that proposals can overwrite one another, e.g., an update and a > remove for the same slot > * If we refactor in the above form, an application could reconstruct what > we have now by always sending a (Proposal, Commit) combo > * In fact, one way to view this is as splitting off the Commit from the > current Handshake messages > > # Benefits > > * We get the objectives that we set out to achieve: > * Quiescent groups can just pile up proposals, and Commit before > messaging > * The server can synthesize Add and Remove proposals as long as > clients have a way to authenticate them (e.g., a designated sender index > for the server) > * There's a certain conceptual simplicity to only having one message that > advances the group state > * With regard to the "ghost account" concerns that DKG raised at the IETF > meeting, this ensures that the proposals to add users are part of the > transcript, thus visible to the group > > # Costs > > * The longer you go before a Commit, the more expensive the Commit is, > since the proposals are all destructive, in the sense that they blank out > parts of the tree > * The logic for a new joiner might get more complicated, since they're no= t > actually added until the Commit. In particular, you can't send an Add > proposal and have the new member immediately able to transmit, you have t= o > do a Commit as well. > * At least in the form above, we lose the property that Adds are constant > time, since you would always do an asymmetric ratchet operation. If this > were a problem, you could special-case it (if the Commit only has Adds...= ) > * Retry logic might get more complicated; need to wait for a Commit befor= e > I know whether my change made it in > * The protocol gets more verbose since you need the glue to refer to the > proposals from the Commit > > ----- > > Thanks for reading all the way to the bottom! > > Personally, I'm pretty split on this. On the one hand, I think this can > be done pretty elegantly. On the other hand, it does feel more complex, > and I'm worried we're spending a lot of complexity budget on some fairly > niche use cases. On the third hand, I do think we need server-initiated > Add/Remove, and all the approaches that come to mind end up looking kind = of > like this > > Happy to have questions / comments here, or if there=E2=80=99s enough int= erest, it > might be good to have a quick phone call. > > =E2=80=94Richard > --000000000000d4a90e0592db2f44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've written up a PR that implements this proposa= l:

Please take a look; there's plenty in there to disagree ab= out, and several OPEN ISSUEs.=C2=A0 I would like to have this landed in the= next week or so, so that we can rebase some other PRs on it (e.g., non-des= tructive add) and publish a new draft for the interim.

=
Thanks,
--Richard

On Thu, Aug 22, 2019 at 6:16 PM R= ichard Barnes <rlb@ipv.sx> wrote:
Hey all,

I=E2=80=99d like t= o pose a question to the group of whether we should do =E2=80=9Claziness=E2= =80=9D or not. =C2=A0 The complete form will be long, but the short version= is: Do we care enough about DH overhead and server-initiated operations to= do a pretty significant refactor and possibly add some complexity to the p= rotocol?

I would like to get a go/no-go on this idea= before writing a PR, since it's going to be a big PR.=C2=A0 And it wou= ld be helpful to make that decision in the next week or two, so that we can= get the edits done and a new version out a bit in advance of the interim.= =C2=A0 So let's get this party started!

# Objec= tives

The overall goal is to meet two objectives:

1. Not requ= iring DH operations in groups where no messaging is happening
2. Allow s= ome flavor of server-initiated Add and Remove

The first of these obj= ectives was raised by Raphael some time ago; see his presentation at the Ja= nuary interim for more details [1].=C2=A0 The second has been a long-outsta= nding feature request, from Facebook and Cisco, among others.

The us= eful insight is that both of these require deferred operations.=C2=A0 In th= e first case, you want to defer DH operations until someone wants to send a= message.=C2=A0 In the second case, you might have the server propose an op= eration that it can=E2=80=99t do, so that the execution of the operation is= deferred until someone in the group does it.

# Proposal

The = proposal here is to refactor the protocol from =E2=80=9Cimmediate mode=E2= =80=9D to =E2=80=9Cdeferred mode=E2=80=9D.=C2=A0 None of the underlying tre= e math changes, just how we talk about it.

* Add, Remove, and Update= become =E2=80=9CProposals=E2=80=9D that describe an operation, rather than= carrying the information to accomplish the information immediately
=C2= =A0 =C2=A0 * Add =3D =E2=80=9CPlease add ${ClientInitKey}=E2=80=9D
=C2= =A0 =C2=A0 * Update =3D =E2=80=9CPlease replace the leaf at ${index} with $= {key} and blank its direct path=E2=80=9D
=C2=A0 =C2=A0 * Remove =3D =E2= =80=9CPlease =C2=A0remove the member at ${index}
* Each epoch contains a= set of proposals, followed by a Commit message
=C2=A0 =C2=A0 * None of = the proposed changes take effect until the Commit message
=C2=A0 =C2=A0 = * If there are outstanding proposals, you SHOULD send a Commit before sendi= ng a message
* A Commit message contains:
=C2=A0 =C2=A0 * A desc= ription of which proposals were applied and how
=C2=A0 =C2=A0 * In par= ticular, the committer chooses the positions where new members are added=C2=A0 =C2=A0 * A direct path that KEMs new entropy to the group (basicall= y an update from the Committer)
* The committer also generates Welcome m= essages for any new participants
=C2=A0 =C2=A0 * With handshake enc= ryption, the Welcome just needs to have the key for the Commit
= =C2=A0=C2=A0=C2=A0 * The Commit should commit to the state of the tree afte= r the proposals are executed (just like handshake messages do today)
<= div>=C2=A0=C2=A0=C2=A0 * ... so the new joiner doesn't need to see the = proposals, just the Commit

# Observations

* In the= framework above, there's no need to synchronize proposals, just Commit= s
* If the Commit includes the proposals by value or hash, then w= e can just run the transcript over the Commit messages, and the proposals w= ill be included transitively
* Note that proposals can overwr= ite one another, e.g., an update and a remove for the same slot
* If we refactor in the above form, an application could reconstruct wha= t we have now by always sending a (Proposal, Commit) combo
* In f= act, one way to view this is as splitting off the Commit from the current H= andshake messages

# Benefits

* We get the objectives that we set out to achieve:
=C2=A0=C2=A0= =C2=A0 * Quiescent groups can just pile up proposals, and Commit before mes= saging
=C2=A0=C2=A0=C2=A0 * The server can synthesize Add and Rem= ove proposals as long as clients have a way to authenticate them (e.g., a d= esignated sender index for the server)
* There's a certai= n conceptual simplicity to only having one message that advances the group = state
* With regard to the "ghost account" concerns tha= t DKG raised at the IETF meeting, this ensures that the proposals to add us= ers are part of the transcript, thus visible to the group

# Costs

* The longer you go before a Commit, the = more expensive the Commit is, since the proposals are all destructive, in t= he sense that they blank out parts of the tree
* The logic fo= r a new joiner might get more complicated, since they're not actually a= dded until the Commit.=C2=A0 In particular, you can't send an Add propo= sal and have the new member immediately able to transmit, you have to do a = Commit as well.
* At least in the form above, we lose the pro= perty that Adds are constant time, since you would always do an asymmetric = ratchet operation.=C2=A0 If this were a problem, you could special-case it = (if the Commit only has Adds...)
* Retry logic might get more= complicated; need to wait for a Commit before I know whether my change mad= e it in
* The protocol gets more verbose since you need the glue = to refer to the proposals from the Commit

-----

Thanks for reading all the way to the bottom!

Personally, I'm pretty split on this.=C2=A0 On t= he one hand, I think this can be done pretty elegantly.=C2=A0 On the other = hand, it does feel more complex, and I'm worried we're spending a l= ot of complexity budget on some fairly niche use cases.=C2=A0 On the third = hand, I do think we need server-initiated Add/Remove, and all the approache= s that come to mind end up looking kind of like this

Happy to have questions / comments here, or if there=E2=80=99s enoug= h interest, it might be good to have a quick phone call.

=E2=80=94= Richard
--000000000000d4a90e0592db2f44-- From nobody Thu Sep 19 06:59:51 2019 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 6EDF5120090 for ; Thu, 19 Sep 2019 06:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=fb.com header.b=isRSpbad; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=GoexWPWX 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 kIX1MdhNQkVj for ; Thu, 19 Sep 2019 06:59:47 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 124B912004C for ; Thu, 19 Sep 2019 06:59:47 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8JDwap7029007 for ; Thu, 19 Sep 2019 06:59:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=aLOYuTAiahEf7MUqEpgb3wBDVVWSgCALNhl1gmv8yfA=; b=isRSpbadSGjVTiTcme0Bdnni2YhAT7ZXEakvm5SxSVWqDzFTAoD/25UEPbEwc2EKmwgU WJaXykSxLJXeqMyqb3AmXdaHS8TNxDKoXJCCDBAaB0hGYDnbYP0gAtn0Yp8bhv7Hsj2Z fJ+yg39YT7W4ccJlBs42cT/zKLr+FJbdQr8= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2v4as7g2h4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 19 Sep 2019 06:59:45 -0700 Received: from ash-exopmbx101.TheFacebook.com (2620:10d:c0a8:82::b) by ash-exhub202.TheFacebook.com (2620:10d:c0a8:83::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 19 Sep 2019 06:59:44 -0700 Received: from ash-exhub201.TheFacebook.com (2620:10d:c0a8:83::7) by ash-exopmbx101.TheFacebook.com (2620:10d:c0a8:82::b) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 19 Sep 2019 06:59:43 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.36.101) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 19 Sep 2019 06:59:43 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RABlm7mx2iO4o5ykU6p6wHHjSz6bsvSyjUs7WF3l6iLfWHAeSFkN5g0M2xT3MJXJMnqL1la2Fs/ft5e7TZ5p38RntNbCfVqaW9AdQFRAc26c+RQF+cA080a3912JGGXZuPyYNuEuJ0CKct8Ym/L8GN1mNxVcwCwucTMfHbHvb1Yfaeuw7HbE2rz+LOGrKw7MuEG2KXC4LJyzz8F4+zBUWEeiIPf6ipIYzb5h9ZnBHBFkw9iyM+t+4by7Ee1OySh0OFs1GmdArYHf8+N/fYVOP8FgRvITgeDIVgB51FzA554tKd3Ks16wchvyVMSdkARhHhWDtAgp0yOLTcggzTzgZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLOYuTAiahEf7MUqEpgb3wBDVVWSgCALNhl1gmv8yfA=; b=JQo8XCqEHfX4DWHkANG01EqZi2HJfHehdGP8YWRGV2HdB0CBkhlWTod7B0KBmWG3K1ASID8uQpDYJgOm2mBjVzazIJaML7OQjhmjx5Us1dbcFBiJLTSvV13CoRbgrNZAunQaVj4lU2zGaPIDksJBB/yXgcmj7Bi4C29PB8sZrwjMDeKe9oEKJPx/svejxa2Afup2WjovDrmeEVTq367YkiVS+maqggAsvI77rsP2Lk3otCk3E1Q+TSCMeTPSx1SgLhLCVOSRU1u2Xhhv/KjQB8Is/0nKyn8NrwJP9fXBhnK3WkCdJMkZjoRsEVgs3XBQVTXnMKpM84gnf3UTcecgGg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLOYuTAiahEf7MUqEpgb3wBDVVWSgCALNhl1gmv8yfA=; b=GoexWPWXQXxMmhwmTFGSRpBAbrauo5c+D3Pc6PYfgIQtJpDclHhaLEicisFvAbfc0tDVAKmCIZa7tRgKL+eZekxCboNzi3V3Ye/AiXLxNsVAw1kFY4+jnCQI5gBGHTbacxTAI0xZslv7kYKq7mnA61+6LjlhN6M94d/MzcPs70Q= Received: from MN2PR15MB3405.namprd15.prod.outlook.com (20.179.21.203) by MN2PR15MB3280.namprd15.prod.outlook.com (20.179.20.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.26; Thu, 19 Sep 2019 13:59:42 +0000 Received: from MN2PR15MB3405.namprd15.prod.outlook.com ([fe80::74ac:89c2:b0d9:4099]) by MN2PR15MB3405.namprd15.prod.outlook.com ([fe80::74ac:89c2:b0d9:4099%3]) with mapi id 15.20.2284.009; Thu, 19 Sep 2019 13:59:42 +0000 From: Jon Millican To: "mls@ietf.org" Thread-Topic: [MLS] Proposal: Proposals (was: Laziness) Thread-Index: AQHVWTdobTpMInhPYUalq6nvDa7Ui6cIchsAgAAVaICAABFGAIAADluAgAACSICAAB07AIAAAumAgAAHi4CAACsVgIAAWwOAgAXuuwCABKrHgIAfUpaA Date: Thu, 19 Sep 2019 13:59:42 +0000 Message-ID: <46673A73-0D73-4206-9DBE-009CA8B4F9B5@fb.com> References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com> In-Reply-To: <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:200::1:3050] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa41e465-0d2d-40df-5453-08d73d099eea x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR15MB3280; x-ms-traffictypediagnostic: MN2PR15MB3280: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(376002)(136003)(53754006)(199004)(189003)(14454004)(229853002)(2906002)(81156014)(316002)(7736002)(86362001)(8936002)(5640700003)(99286004)(5660300002)(6116002)(36756003)(2501003)(25786009)(6486002)(2616005)(486006)(5024004)(66446008)(446003)(46003)(14444005)(478600001)(561944003)(53546011)(606006)(6506007)(186003)(256004)(476003)(76176011)(33656002)(11346002)(76116006)(71200400001)(91956017)(64756008)(30864003)(66476007)(66556008)(6512007)(6436002)(81166006)(54896002)(966005)(2351001)(71190400001)(6246003)(66946007)(6306002)(236005)(6916009)(102836004)(8676002)(1730700003)(60764002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR15MB3280; H:MN2PR15MB3405.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 76Vu8nn/6RPYA4yRLNBj4n9k4HE+qz8ygkjCUpizdnXIG1cfQuMq1Qfsb+A1fNWfHD7M7duWrFevCCpIghWhPDrn5w+AMGaTexsWfHO/q4Wdh6/2fvo06DDDtsQssi9/cXvYI7iluPW0EgVqNKEPhnUzdDZ+av3LcpDoxGo62dG/g0WdHE9Kd1I4SXyBKBmqulSFWfQrjNcYulWyj+N+ntsnjHBhZJqFuVfowzUg95wu2o7shF0aCOEwvinQnltzqyTbgAUZ5zYx+/TYiNgyZdin3MakpouGBhR4WRJUFAn6D+gti9j2JReW+fEZAb1Z59x9UER42mbP/DGhGlseSQw5IHsyLnv46+BaKD6Igl+ORvN2NAjykCFTILwDmKlazSNjn+FLiXq3yDD5RKao6a6gLz3gYkUM4pjNZP4z2Qg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_46673A730D7342069DBE009CA8B4F9B5fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aa41e465-0d2d-40df-5453-08d73d099eea X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 13:59:42.5482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3qgCLa8kUHb5hZxGPDLFs1RAE6prBgQAS5cQOFGfcrEDw/AznohLMB2eXk+Mo1yWBhb/BcaA5IrFIAlhixYsaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB3280 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-19_04:2019-09-19,2019-09-19 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 impostorscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=999 clxscore=1011 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909190132 X-FB-Internal: deliver Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 13:59:50 -0000 --_000_46673A730D7342069DBE009CA8B4F9B5fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgZm9yIGp1bXBpbmcgb250byB0aGlzIHRocmVhZCBxdWl0ZSBsYXRlLCBidXQganVzdCBh IGNvdXBsZSBjb21tZW50cyB0byBhZGQ6DQoNCj4gIENhbiBVcGRhdGUgUHJvcG9zYWxzIGJlIGlz c3VlZCBieSBhbnlvbmUgYnV0IHRoZSBtZW1iZXIgaXRzZWxmPyBJZiB3ZSBzYXkgeWVzLCB0aGUg YW5hbHlzaXMgd2lsbCBiZSBtb3JlIHN0cmFpZ2h0IGZvcndhcmQsIGJ1dCBpdCBpcyBhbHNvIG1v cmUgbGltaXRlZC4gSWYgd2Ugc2F5IG5vLCB0aGUgcXVlc3Rpb24gcmVtYWlucyB3aG8gY2FuIGlz c3VlIHRoZW0uIFRoZXkgY291bGQgYmUgaXNzdWVkIGJ5IHRoZSBzZXJ2ZXIgb3IgYW5vdGhlciBt ZW1iZXIuIFJpZ2h0IG5vdyBJIGRvbuKAmXQgc2VlIHdoeSBhbm90aGVyIG1lbWJlciBzaG91bGQg YmUgYWxsb3dlZCB0byBkbyBzbywgYnV0IEkgY291bGQgdGhpbmsgb2YgcmVhc29ucyB3aHkgdGhl IHNlcnZlciBzaG91bGQgYmUgYWxsb3dlZCB0byBkbyBzbyAobXVsdGktZGV2aWNlIGNvbnRleHQp LiBXZSBzaG91bGQgYWdhaW4gYmUgdmVyeSBjYXJlZnVsIHcuci50IHRoZSBnaG9zdCB1c2VyIHNj ZW5hcmlvIGluIG9yZGVyIHRvIGF2b2lkIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZSBzZXJ2ZXIg Y2FuIHNuZWFrIGluIGEgbWFsaWNpb3VzIHBhcnRpY2lwYW50IHRoYXQgd2F5Lg0KDQpJIGRvbid0 IHNlZSBhIGdvb2QgcmVhc29uIGZvciBhbnlvbmUgb3RoZXIgdGhhbiBhIGxlYWYtb3duZXIgdG8g ZXZlciBpc3N1ZSBhbiB1cGRhdGUgdG8gdGhhdCBsZWFmLiBJZiB3ZSB0cmVhdCBtdWx0aS1kZXZp Y2UgYXMgYSBzcGVjaWFsIGNhc2Ugb2YgZ3JvdXAsIHRoZW4gdGhlIHNlcnZlciB3b3VsZCBhbHNv IG5vdCBuZWVkIHRvIGRvIHRoaXMg4oCTIGl0IGNvdWxkIGluc3RlYWQganVzdCBpc3N1ZSBhZGRz IGFuZCByZW1vdmVzIGFzIGRldmljZXMgY2hhbmdlLg0KDQoNCj4gU2VydmVyIGFkZC9yZW1vdmUg aXMgaW1wb3J0YW50IGluIG1hbnkgcHJhY3RpY2FsIHVzZSBjYXNlczogeW91IGJ1eSBhIG5ldyBw aG9uZSBhbmQgbG9nIGluOyB0aGUgc2VydmVyIHdhbnRzIHRvIHJlbW92ZSB5b3VyIG9sZCBwaG9u ZSBmcm9tIGFsbCBncm91cHMgaXQncyBpbiwgYW5kIGFkZCB0aGUgbmV3IHBob25lLg0KDQpUbyBz dHJlc3MgdGhpcyBwb2ludCwgc2VydmVyLWNvbnRyb2xsZWQgZ3JvdXAgbWVtYmVyc2hpcCBpcyBh IHByYWN0aWNhbCBuZWNlc3NpdHkgaW4gbWFueSBjYXNlcy4gSSBjYW7igJl0IHRoaW5rIG9mIGFu eSBzaWduaWZpY2FudCBtZXNzYWdpbmcgc2VydmljZSB0aGF0IGRvZXMgbm90IGFsbG93IGFjY291 bnQgcmVzZXRzLCBhbmQgSSBiZWxpZXZlIHRoZSBtYWpvcml0eSB3aWxsIGFsbG93IG11bHRpLWRl dmljZS9ncm91cCB0aHJlYWRzIHRvIGNvbnRpbnVlIHdoZW4gdGhpcyBoYXBwZW5zLiBGb3IgZXhh bXBsZSwgbWVtYmVyc2hpcCBvZiBhIHRocmVhZCBpbiBNZXNzZW5nZXIgaXMgYmFzZWQgb24gdXNl ciBhY2NvdW50IHJhdGhlciB0aGFuIGRldmljZSDigJMgaWYgYSBkZXZpY2UgaXMgYXR0YWNoZWQg dG8gYSBnaXZlbiB1c2VyIGFjY291bnQsIHRoZW4gaXQgaXMgaW5oZXJlbnRseSBpbiBhbnkgdGhy ZWFkcyB0aGF0IHRoaXMgdXNlciBhY2NvdW50IGlzIGFsc28gaW4uIExvZ2dpbmcgaW50byBhbiBh Y2NvdW50IGlzIG5vdCBhIGNyeXB0b2dyYXBoaWMgcHJvY2VzcyBhdHRhY2hlZCB0byBzb21lIG90 aGVyIGRldmljZSwgYnV0IGF1dGhlbnRpY2F0aW5nIHRvIGFuIG9ubGluZSBzZXJ2aWNlIChlLmcu IHVzZXJuYW1lICsgcGFzc3dvcmQpLiBJIGJlbGlldmUgV2lyZSBmb2xsb3dzIHRoZSBzYW1lIG1v ZGVsLiBJbiB0aGlzIHdvcmxkLCBhIGRldmljZSB3aGljaCBsb2dzIGludG8gYW4gYWNjb3VudCBu ZWVkcyB0byBiZSBhYmxlIHRvIG5vdCBvbmx5IHJlY2VpdmUgZnV0dXJlIG1lc3NhZ2VzIHRvIHRo YXQgYWNjb3VudOKAmXMgdGhyZWFkcyAod2hpY2ggY291bGQgYmUgYWNoaWV2ZWQgYXQgdGhlIGFw cGxpY2F0aW9uIGxldmVsIHdpdGhvdXQgc2VydmVyLWFkZCksIGJ1dCBhbHNvIHRvIHNlbmQgbWVz c2FnZXMgdG8gYW55IG9mIHRoZXNlIHRocmVhZHMgKHBvdGVudGlhbGx5IGJlZm9yZSBhbnkgb3Ro ZXIgZGV2aWNlIGluIHRoZSB0aHJlYWQgaGFzIGNvbWUgb25saW5lKSDigJMgd2hpY2ggd291bGQg YmUgbW9yZSBjaGFsbGVuZ2luZyB0byBpbXBsZW1lbnQgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVs LiBGb3IgdGhpcyByZWFzb24sIEnigJlkIHN0cm9uZ2x5IGZhdm91ciBzZXJ2ZXIgYWRkIGluIHRo ZSBwcm90b2NvbC4NCg0KSm9uDQoNCg0KRnJvbTogTUxTIDxtbHMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIEthdHJpZWwgQ29obi1Hb3Jkb24gPG1lQGthdHJpZWwuY28udWs+DQpEYXRl OiBGcmlkYXksIDMwIEF1Z3VzdCAyMDE5IGF0IDE3OjQxDQpUbzogIm1sc0BpZXRmLm9yZyIgPG1s c0BpZXRmLm9yZz4NCkNjOiBNZXNzYWdpbmcgTGF5ZXIgU2VjdXJpdHkgV0cgPG1sc0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbTUxTXSBQcm9wb3NhbDogUHJvcG9zYWxzICh3YXM6IExhemluZXNz KQ0KDQpUaGlzIGFic3RyYWN0aW9uIHNlZW1zIHNlbnNpYmxlLiBTZXJ2ZXIgYWRkL3JlbW92ZSBp cyBpbXBvcnRhbnQgaW4gbWFueSBwcmFjdGljYWwgdXNlIGNhc2VzOiB5b3UgYnV5IGEgbmV3IHBo b25lIGFuZCBsb2cgaW47IHRoZSBzZXJ2ZXIgd2FudHMgdG8gcmVtb3ZlIHlvdXIgb2xkIHBob25l IGZyb20gYWxsIGdyb3VwcyBpdCdzIGluLCBhbmQgYWRkIHRoZSBuZXcgcGhvbmUuIFNpbmNlIHdl IG9mIGNvdXJzZSBkb24ndCB3YW50IHRvIGdpdmUgdGhlIHNlcnZlciB0aGUgYWJpbGl0eSB0byBh Y3R1YWxseSBlZmZlY3QgdGhpcyBjaGFuZ2UsIG9ubHkgdG8gcHJvcG9zZSBpdCwgaXQgc2VlbXMg dG8gbWUgdGhhdCB3ZSBhbHJlYWR5IG5lZWQgYSB3YXkgdG8gZGlzY29ubmVjdCBwcm9wb3NhbHMg YW5kIGNvbW1pdHMgYW55d2F5LiBPbmNlIHRoYXQncyB0aGUgY2FzZSwgaXQgZG9lc24ndCBzZWVt IHRvbyBiaWcgYSBsZWFwIHRvIGNsZWFubHkgZmFjdG9yIGFsbCBvcGVyYXRpb25zIGludG8gdGhh dCBzdHJ1Y3R1cmUuDQoNCk15IG1haW4gd29ycnkgd291bGQgYmUgY29tcGxpY2F0aW5nIHRoZSBh bmFseXNpcy4gSG93ZXZlciwgaXQgc2VlbXMgbGlrZSBpZiB0aGUgc2VwYXJhdGlvbiBpcyBjbGVh biBlbm91Z2ggdGhlbiBpdCBtaWdodCBub3QgYWN0dWFsbHkgbWFrZSB0aGUgYW5hbHlzaXMgdG9v IGJhZCwgYmVjYXVzZSB0aGVyZSBpcyBhIGNsZWFuIHByb3BlcnR5ICh0aGF0IEthcnRoaWsgZGVz Y3JpYmVkKSBmb3IgZWFjaCBlcG9jaCBjaGFuZ2UuIFNvLCBvbiBiYWxhbmNlLCBJIHRoaW5rIEkn bSBpbiBmYXZvdXIgb2YgdGhpcyBwcm9wb3NhbC4NCg0KLS1rYXRyaWVsDQoNCk9uIFR1ZSwgMjcg QXVnIDIwMTksIGF0IDY6MjMgUE0sIEthcnRoaWsgQmhhcmdhdmFuIHdyb3RlOg0KDQpIaSBSaWNo YXJkLA0KDQpPbiAyMyBBdWcgMjAxOSwgYXQgMTg6NDgsIFJpY2hhcmQgQmFybmVzIDxybGJAaXB2 LnN4PG1haWx0bzpybGJAaXB2LnN4Pj4gd3JvdGU6DQoNCkp1c3QgdG8gY29uZmlybSBJIHVuZGVy c3RhbmQsIHRoZSBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wgaW4gdGhpcyBjb25jZXB0aW9uIHdvdWxk IGJlIHNvbWV0aGluZyBsaWtlLCBhdCBlYWNoIGVwb2NoOg0KDQoxLiBLRU0gYSBzZWNyZXQgdG8g c29tZSBzZXQgb2YgcGVvcGxlIHdob20geW91IGJlbGlldmUgdG8gYmUgdGhlIGN1cnJlbnQgbWVt YmVycyBvZiB0aGUgZ3JvdXANCjIuIFNlbmQgdGhhdCBLRU0nZWQgdmFsdWUgb3V0IHRvIHRoZSBn cm91cCB0b2dldGhlciB3aXRoIGEgZGVzY3JpcHRpb24gb2YgdGhlIGN1cnJlbnQgbWVtYmVyc2hp cA0KMy4gS0RGIHRoZSBLRU0nZWQgc2VjcmV0IHRvZ2V0aGVyIHdpdGggdGhlIHByaW9yIGVwb2No IHNlY3JldCB0byBnZXQgdGhlIG5ldyBlcG9jaCBzZWNyZXQNCjQuIFVzZSB0aGUgbmV3IGVwb2No IHNlY3JldCB0byBnZW5lcmF0ZSBhIGNvbmZpcm1hdGlvbiBvdmVyIHRoZSBjdXJyZW50IHN0YXRl IG9mIHRoZSBncm91cA0KV2hlcmUgdGhlIEtFTSBpbiAoMSkgd291bGQgYmUgc29tZXRoaW5nIGxp a2UgVHJlZUtFTSBvciBqdXN0ICJlbmNyeXB0IHRvIGEgbGlzdCBvZiBwdWJsaWMga2V5cyIuICBU aGVuIHRoZSBwcm9wb3NhbHMgd291bGQganVzdCBiZSBhIHdheSBmb3IgcGVvcGxlIHRvIHN5bmMg dXAgb24gd2hvIHRoZSBjdXJyZW50IG1lbWJlcnMgb2YgdGhlIGdyb3VwIGFyZSAoYnkgbGVhZiBr ZXkpLg0KDQpUaGlzIGlzIGVzc2VudGlhbGx5IGNvcnJlY3QsIG9mIGNvdXJzZSB3aXRoIGEgYnVu Y2ggb2YgZGV0YWlscyB0byBndWFyYW50ZWUgdGhhdCBldmVyeW9uZSBnZXRzIHRoZSBzYW1lIGtl eXMuDQpJdCByZW1haW5zIG1vc3RseSB1bmNoYW5nZWQgZnJvbSB3aGF0IHdlIGhhdmUgY3VycmVu dGx5Lg0KDQpUaGUgbWFqb3IgdGhpbmcgSSB3b3VsZCBiZSB3b3JyaWVkIGFib3V0IGluIHN1Y2gg YSBzcGxpdCBpcyBob3cgaXQgd291bGQgZGVhbCB3aXRoIGF1dGhvcml0eSBvdmVyIGNoYW5nZXMs IHdoaWNoIGFmZmVjdCB0aGUgYXV0aGVudGljYXRpb24gcHJvcGVydGllcyBvZiB0aGUgcHJvdG9j b2wuICBUaGUgY3VycmVudCBQcm9wb3NhbHMgcHJvcG9zYWwgbWFpbnRhaW5zIHRoZSBwcm9wZXJ0 eSB0aGF0IGV2ZXJ5b25lIGFncmVlcyBvbiB0aGUgcHJvcG9zYWxzIGFuZCBjYW4gdmVyaWZ5IHRo YXQgdGhleSB3ZXJlIHByb3BlciwgZS5nLiwgb25seSB0aGUgaG9sZGVyIG9mIGEgbGVhZiBjYW4g dXBkYXRlIHRoYXQgbGVhZi4gIElmIHdlIHNldmVyIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gdGhl IHByb3Bvc2FscyBhbmQgdGhlIHRvcC1sZXZlbCB0cmFuc2NyaXB0IGVudGlyZWx5LCB0aGVuIEkn bSBub3Qgc3VyZSBob3cgeW91IHdvdWxkIGNvbnRpbnVlIHRvIGFzc3VyZSB0aGF0LCBzYXksIHRo ZSBzZW5kZXIgb2YgYSBDb21taXQgZGlkbid0IGp1c3Qgc3dhcCBvdXQgSm9lJ3MgbGVhZiBrZXkg Zm9yIHRoZSBOU0EuDQoNClRoZSBjaGFuZ2VzIHdvdWxkIGJlIHNpZ25lZCBieSB0aGUgc2VuZGVy LCBhcyB1c3VhbC4gVGhlIG9ubHkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGlzIHNpZ25hdHVyZSBp cyBlbm91Z2gsIHdpdGhvdXQgYmluZGluZyB0aGUgc2lnbmF0dXJlIHRvIHRoZSBrZXkgZXhjaGFu Z2UgdHJhbnNjcmlwdCBvciBjdXJyZW50IGVwb2NoIHNlY3JldC4NCk5vdGUgdGhhdCB0aGUgdHJl ZSBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2wgaGFzIGl0cyBvd24gdHJhbnNjcmlwdCBvbiBob3cg dGhlIHRyZWUgaGFzIGNoYW5nZWQgb3ZlciB0aW1lLCBhbmQgY2VydGFpbmx5IHdlIGNvdWxkIHJl cXVpcmUgZWFjaCB1cGRhdGUgdG8gc2lnbiB0aGlzIOKAnHN0YXRlIGhpc3RvcnnigJ0gdHJhbnNj cmlwdC4NCldlIHNob3VsZCBvZiBjb3Vyc2UgaW1wb3NlIHRoZSByZXF1aXJlbWVudCB0aGF0IG9u bHkgdGhlICJob2xkZXIgb2YgdGhlIHNpZ25hdHVyZSBrZXkgY29ycmVzcG9uZGluZyB0byBhIGxl YWbigJ0gY2FuIHVwZGF0ZSB0aGF0IGxlYWYuDQpJbiBmYWN0LCB0aGUgdHJlZSB1cGRhdGUgcHJv dG9jb2wgY2FuIGVuc3VyZSB0aGF0IG9ubHkgbWVtYmVycyBvZiBhIHN1YnRyZWUgY2FuIGNoYW5n ZSB0aGUgcm9vdCBvZiB0aGF0IHN1YnRyZWUuDQpUaGlzIGlzIHdoYXQgd2UgZ3VhcmFudGVlIG5v dyBhbnl3YXkuIEkgZG9u4oCZdCBzZWUgdGhhdCBzdWJzdGFudGlhbGx5IGNoYW5naW5nIGluIHRo ZSBkZWNvdXBsZWQgZGVzaWduLg0KDQoNCkkgYWdyZWUgdGhhdCB0aGVyZSBpcyBkZWdyZWUgb2Yg c2VwYXJhdGlvbiBoZXJlIChzaW5jZSwgZS5nLiwgaXQncyBlYXN5IHRvIGltYWdpbmUgc3dhcHBp bmcgaW4gYSAibGlzdCBvZiBrZXlzIiBLRU0gZm9yIFRyZWVLRU0pLiAgQnV0IGl0IHNlZW1zIGxp a2UgYSBmYWlybHkgaGlnaCBkZWdyZWUgb2YgY291cGxpbmcgaXMgbmVjZXNzYXJ5IHRvIG1haW50 YWluIGF1dGhlbnRpY2F0aW9uLg0KDQpTbywgd2hhdCB3b3VsZCBiZSB0aGUgYXV0aGVudGljYXRp b24gcHJvcGVydHkgeW91IHdvdWxkIHdhbnQgZm9yIGEgdHJlZSBjaGFuZ2U/DQpUaGUgdHJlZSBj aGFuZ2luZyBzZW5kZXIgbXVzdCBrbm93IHRoZSBzaWduYXR1cmUga2V5IGZvciBhIG1lbWJlciAq YW5kIG11c3QgYWxzbyBrbm93IHRoZSBjdXJyZW50IGVwb2NoIHNlY3JldCo/DQoNClBlcmhhcHMg d2hhdCB5b3UgYXJlIHBvaW50aW5nIG91dCBpcyB0aGF0IHdlIGNhbm5vdCByZW1vdmUgc2lnbmF0 dXJlcyBmcm9tIHRoZSBrZXkgZXhjaGFuZ2UgcHJvdG9jb2wsIGFuZCBzbyB3ZeKAmWQgZW5kIHVw IG5lZWRpbmcgdHdvIHNpZ25hdHVyZXM7IG9uZSBmb3IgdHJlZSBzeW5jaHJvbml6YXRpb24gYW5k IHRoZSBvdGhlciBmb3IgYXV0aGVudGljYXRpbmcgdGhlIGtleSBleGNoYW5nZS4NCkFjdHVhbGx5 LCB3ZSBhbHNvIG5lZWQgYSB0aGlyZCBzaWduYXR1cmUgZm9yIHRoZSBtZXNzYWdlIHByb3RlY3Rp b24uIEhvdyBhbmQgd2hlbiB3ZSBjYW4gc2hhcmUgdGhlc2Ugc2lnbmF0dXJlcyBpcyBhbiBvcHRp bWl6YXRpb24gcHJvYmxlbSwgYnV0IHRoZXkgc2VydmUgZGlmZmVyZW50IHB1cnBvc2VzLg0KDQot S2FydGhpaw0KDQoNCi0tUmljaGFyZA0KDQoNCg0KT24gRnJpLCBBdWcgMjMsIDIwMTkgYXQgMToy MiBQTSBLYXJ0aGlrIEJoYXJnYXZhbiA8a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPG1h aWx0bzprYXJ0aGlrZXlhbi5iaGFyZ2F2YW5AaW5yaWEuZnI+PiB3cm90ZToNCkhlbGxvIEFsbCwN Cg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBvbmUgd2F5IHRvIHRoaW5rIGFib3V0IOKAnGxhemluZXNz 4oCdIHdvdWxkIGJlIHRvIGNsZWFubHkgc2VwYXJhdGUgdGhlIE1MUyBrZXkgZXhjaGFuZ2UgaW50 byB0d28gZGlmZmVyZW50IHByb3RvY29scy4NClRoZSBmaXJzdCBpcyBhIOKAnGNsYXNzaWPigJ0g YXV0aGVudGljYXRlZCBzeW5jaHJvbml6YXRpb24gcHJvdG9jb2wgd2hlcmUgbWVtYmVycyBvZiBh IGdyb3VwIGNhbiBjcmVhdGUgYW5kIG1vZGlmeSBhIHNoYXJlZCBkYXRhIHN0cnVjdHVyZSAoaW4g dGhpcyBjYXNlLCB0aGUgZ3JvdXAgbWVtYmVyc2hpcCB0cmVlKS4NClRoZSBzZWNvbmQgaXMgYSBu b3ZlbCBrZXkgZXN0YWJsaXNobWVudCBwcm90b2NvbCB3aGVyZSBzb21lIG1lbWJlciBvZiB0aGUg Z3JvdXAgZ2VuZXJhdGVzIGEgZnJlc2ggZ3JvdXAgc2VjcmV0IHRoYXQgd2lsbCBiZSBkZWxpdmVy ZWQgb25seSB0byB0aGUgY3VycmVudCBtZW1iZXJzIGNvbXB1dGVkIGZyb20gdGhlIChjdXJyZW50 KSBncm91cCBzdGF0ZS4NCkN1cnJlbnRseSB0aGUgZmlyc3QgYW5kIHNlY29uZCBwcm90b2NvbHMg YXJlIHRpZ2h0bHkgaW50ZXJsZWF2ZWQ6IGV2ZXJ5IHRpbWUgdGhlIGdyb3VwIGRhdGEgc3RydWN0 dXJlIGlzIG1vZGlmaWVkIGJ5IHNvbWUgbWVtYmVyIChvciBhZG1pbiksIHRoYXQgbWVtYmVyIG11 c3QgYWxzbyBnZW5lcmF0ZSBhbmQgZGlzdHJpYnV0ZSB0aGUgZnJlc2ggZ3JvdXAgc2VjcmV0Lg0K VGhlIGxhemluZXNzIHByb3Bvc2FsIGNhbiBiZSB0aG91Z2h0IG9mIGFzIGRldGFjaGluZyB0aGUg dHdvIHByb3RvY29sczogdGhlIGtleSBlc3RhYmxpc2htZW50IHByb3RvY29sIGNhbiBmb2xsb3cg Z3JvdXAgbW9kaWZpY2F0aW9ucyB3aXRoIHNvbWUgZGVsYXkuDQoNClNvIHJhdGhlciB0aGFuIHRy eWluZyB0byBhZGQg4oCcbGF6aW5lc3PigJ0gdG8gdGhlIGV4aXN0aW5nIHByb3RvY29sLCBzaG91 bGQgd2UgdHJ5IHRvIGRvIHRoaXMgZGV0YWNobWVudCBpbiBhIHByaW5jaXBsZWQgd2F5IGJ5IGRl ZmluaW5nIHR3byBpbmRlcGVuZGVudCBzdWItcHJvdG9jb2xzPw0KSXQgd291bGQgaGF2ZSB0aGUg YWR2YW50YWdlIHRoYXQgd2UgbWF5IGJlIGFibGUgdG8gY29uc2lkZXIgb3RoZXIgZGVzaWducyBm b3Igc3luY2hyb25pemF0aW9uIGFuZCBrZXkgZXN0YWJsaXNobWVudCwgd2hpY2ggbWF5IHdlbGwg YmUgb3J0aG9nb25hbCBjb25jZXJucy4NCg0KSW4gb3VyIG1vZGVsIG9mIE1MUywgd2UgY2FuIGFs cmVhZHkgZmFjdG9yIG91dCB0aGUgcHJvdG9jb2wgaW4gdGhpcyB3YXksIGJ1dCBpdCBtYWtlcyB0 aGUgc2VjdXJpdHkgaW52YXJpYW50cyBhIGJpdCBoYXJkZXIgdG8gZXhwcmVzcyBpbiBhIHVzZXIt ZnJpZW5kbHkgd2F5Lg0KU3RpbGwsIEkgd291bGQgcHJlZmVyIHRvIGNvbXBvc2UgcHJvb2ZzIGZv ciBzaW1wbGVyIHN1Yi1wcm90b2NvbHMgcmF0aGVyIHRoYW4gdHJ5IHRvIHByb3ZlIHNlY3VyaXR5 IGZvciBhIHNpbmdsZSBjb21wbGV4IHByb3RvY29sIHdpdGggbG90cyBvZiBvcHRpb25zLg0KDQpC ZXN0LA0KLUthcnRoaWsNCg0KDQpPbiAyMyBBdWcgMjAxOSwgYXQgMTA6NDgsIFJpY2hhcmQgQmFy bmVzIDxybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2Li5zeD4+IHdyb3RlOg0KDQoNCg0KT24gRnJp LCBBdWcgMjMsIDIwMTkgYXQgMTA6MjEgQU0gU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4gd3JvdGU6DQoN CkhpeWEsDQoNCk9uIDIzLzA4LzIwMTkgMTU6MTAsIFJpY2hhcmQgQmFybmVzIHdyb3RlOg0KPg0K PiBJJ20gbm90IGNsZWFyIG9uIHdoYXQgeW91IG1lYW4gYnkgIm1lYW5pbmdmdWxseSBoYW5kbGVk IGJ5IG1lbWJlcnMiLg0KPg0KDQpJJ20gYXNzdW1pbmcgdGhhdCBNTFMgcHJvdG9jb2wgZGF0YSB3 aWxsIGxpa2VseSBiZQ0KaGFuZGxlZCBieSBhIGxpYnJhcnkuIElTVE0gbW9yZSBsaWtlbHkgdGhh dCBzdWNoIGENCmxpYnJhcnkgbWlnaHQgZGVmYXVsdCB0bywgb3IgYmUgY2FyZWxlc3NseSB1c2Vk IHRvLA0KaG9ub3IgYW55dGhpbmcgdGhlIHNlcnZlciBwcm9wb3NlcyBpZiB0aGlzIGlzIGFuIE1M Uw0KcHJvdG9jb2wgZmVhdHVyZSByYXRoZXIgdGhhbiBhbiBhcHBsaWNhdGlvbiBsYXllcg0KZmVh dHVyZS4gVGhhdCdkIGJlIGFuIGV4YW1wbGUgb2Ygbm90IG1lYW5pbmdmdWxseQ0KaGFuZGxpbmcg dGhpczotKSBXZSBoYXZlIHNlZW4gc2ltaWxhciBraW5kcyBvZg0KZmFpbHVyZSB3aXRoIGFwcGxp Y2F0aW9ucyBhbmQgVExTIGxpYnJhcmllcyBpbiB0aGUNCnBhc3Qgd2hlcmUgY2VydHMgYXJlbid0 IGNoZWNrZWQgZXRjLg0KDQpPaCBJIHNlZS4gIFRoYXQgd291bGQgYWN0dWFsbHkgYmUgYSBwcmV0 dHkgZGlmZmljdWx0IHBvbGljeSB0byBpbXBsZW1lbnQsIGF0IGxlYXN0IHdpdGhvdXQgdHVybmlu ZyBvZmYgYXV0aGVudGljYXRpb24gYWx0b2dldGhlciwgYXQgbGVhc3QgaW4gdGhlIGVudmlzaW9u ZWQgcHJvdG9jb2wuICBCeSB3aGljaCBJIG1lYW46DQoNCi0gUmlnaHQgbm93LCBjbGllbnRzIGFy ZSBleHBlY3RlZCB0byBtYWludGFpbiBhIGxpc3Qgb2YgbWVtYmVycycgc2lnbmluZyBrZXlzDQot IFNvIHNpZ25lcnMgYXJlIGp1c3QgaW5kaWNhdGVkIGJ5IHRoZWlyIGluZGV4IGluIHRoYXQgbGlz dA0KLSBUaGUgb2J2aW91cyB3YXkgdG8gYWRkIG5vbi1tZW1iZXIgc2lnbmVycyBpcyB0byByZXNl cnZlIGEgYmxvY2sgb2YgaW5kaWNlcyAoc2F5IDB4RkZGRkZGeHgpIHRoYXQgY2FuIGNvcnJlc3Bv bmQgdG8gYXBwbGljYXRpb24tc3BlY2lmaWMgZW50aXRpZXMNCi0gVGhlbiBjbGllbnRzIG5lZWQg dG8gZ2V0IGNvbmZpZ3VyZWQgd2l0aCB3aGljaCBzZXJ2ZXIga2V5cyBnbyB3aXRoIHdoaWNoIHJl c2VydmVkIGluZGljZXMNCg0KQXNzdW1pbmcgd2UgZ28gaW4gdGhhdCBkaXJlY3Rpb24sIHRoZSBu YXR1cmFsLCAiSSBkb24ndCBjYXJlIGFib3V0IHNlcnZlci1pbml0aWF0ZWQgc3R1ZmYiIGxpYnJh cnkgZGVzaWduIHdvdWxkIGJlIHRvIGp1c3Qgbm90IGltcGxlbWVudCBhbnkgc3BlY2lhbCBoYW5k bGluZyBmb3IgdGhvc2UgcmVzZXJ2ZWQgaW5kaWNlcywgaW4gd2hpY2ggY2FzZSB5b3UnbGwgcmVq ZWN0IGFueXRoaW5nIGZyb20gdGhlIHNlcnZlci4gIEkgd291bGQgZXhwZWN0IGEgbGlicmFyeSB0 aGF0IGRvZXMgYW55dGhpbmcgZWxzZSB0byBoYXZlIGFuIEFQSSBmb3IgdGhlIGNvbmZpZ3VyYXRp b24gcmVxdWlyZWQgaW4gdGhlIGxhc3QgcG9pbnQuDQoNClRoZSBvYnZpb3VzIHNjcmV3LXVwIGNh c2Ugd291bGQgYmUsICJUcmVhdCBhIHNpZ25hdHVyZSBmcm9tIHRoZSByZXNlcnZlZCBibG9jayBh cyB0cnVzdGVkIi4gIEJ1dCB0aGF0J3MgYWN0dWFsbHkgYSBsaXR0bGUgaGFyZCB0byBpbXBsZW1l bnQ7IGJlY2F1c2UgdGhlIHB1YmxpYyBrZXlzIGFyZW4ndCBwcm92aWRlZCwgeW91IHdvdWxkIGhh dmUgdG8gYWxzbyBub3QgZG8gYW55IHNpZ25hdHVyZSB2ZXJpZmljYXRpb24gYXQgYWxsLCB3aGlj aCBtZWFucyB5b3UncmUgbm93IHRvdGFsbHkgb3BlbiB0byB0aGUgd29ybGQuICBIb3BlZnVsbHkg dGhhdCB3b3VsZCByYWlzZSBzb21lIHJlZCBmbGFncyBmb3IgZGV2ZWxvcGVycy4NCg0KU28gaXQn cyBub3QgaW1wb3NzaWJsZSB0byBzY3JldyB1cCwgYnV0IG5vdCB0cml2aWFsIGVpdGhlci4gIEF0 IGxlYXN0IGlmIHlvdSB3YW50IHRvIG1haW50YWluIGF1dGhlbnRpY2F0aW9uIGZvciBncm91cCBt ZW1iZXJzLiAgSWYgeW91IHR1cm4gdGhhdCBvZmYgdG9vLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBz YXZlIHlvdS4NCg0KLS1SaWNoYXJkDQoNCg0KDQpJIGRvIGFjY2VwdCB0aGUgYXJndW1lbnQgdGhh dCBpdCBjYW4gaGFwcGVuIGF0IHRoZQ0KYXBwbGljYXRpb24gbGF5ZXIgaWYgbm90IGRlZmluZWQg aW4gdGhlIE1MUyBwcm90b2NvbCwNCmJ1dCBkb2luZyB0aGlzIGtpbmQgb2YgdGhpbmcgYXQgdGhl IGFwcGxpY2F0aW9uIGxheWVyDQpzZWVtcyBzYWZlciB0byBtZS4NCg0KSXQncyBhbHNvIG5vdCBj bGVhciB0byBtZSB0aGF0IGFsbCBNTFMgYXBwbGljYXRpb25zDQp3b3VsZCBuZWVkIHRoaXMgZmVh dHVyZS4gKFRoYXQgbWF5IGJlIHRydWUsIEkganVzdA0KZG9uJ3Qga25vdy4pIElmIHRoZXkgZG9u J3QsIHRoZW4gYWdhaW4sIGl0IHNlZW1zIHRvDQpiZSBtb3JlIGNvbnNlcnZhdGl2ZSB0byBsZWF2 ZSBpdCB0byBhcHBsaWNhdGlvbnMuDQoNCkkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgc2hhcnAgZWRn ZXMgaG93ZXZlciB0aGlzIGtpbmQNCm9mIHRoaW5nIGlzIGRvbmUgdGhvdWdoLg0KDQpDaGVlcnMs DQpTLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1M UyBtYWlsaW5nIGxpc3QNCk1MU0BpZXRmLm9yZzxtYWlsdG86TUxTQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19tbHMmZD1Ed01GYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVY X2J2RXFNYTg0USZtPWdhYnNnRzUzT3NSV0pDaHlibXZCUGhQNEJ3dzZkUmJyYnVyOU1aTXFTYkEm cz1qUGVuM3Voa0pTdWctWEdTdFFaZzd2V25feXMxTGVYYlg1TndRUzBDd0NnJmU9Pg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1MUyBtYWlsaW5nIGxp c3QNCk1MU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bHMNCg0KDQo= --_000_46673A730D7342069DBE009CA8B4F9B5fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Z2VvcmdpYTsNCglwYW5vc2UtMToyIDQgNSAyIDUgNCA1IDIgMyAzO30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29Ob1NwYWNpbmcsIGxpLk1zb05vU3BhY2luZywgZGl2 Lk1zb05vU3BhY2luZw0KCXttc28tc3R5bGUtcHJpb3JpdHk6MTsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJ bWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFs MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5xdC1nbWFp bC1tLTgwMzE3Njc1NzMyOTQyMDYyNjRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxl LW5hbWU6cXQtZ21haWwtbV8tODAzMTc2NzU3MzI5NDIwNjI2NGFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLmZvbnQNCgl7bXNvLXN0eWxlLW5hbWU6Zm9udDt9DQpzcGFuLnNpemUNCgl7bXNv LXN0eWxlLW5hbWU6c2l6ZTt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U29ycnkgZm9yIGp1bXBpbmcgb250byB0aGlzIHRo cmVhZCBxdWl0ZSBsYXRlLCBidXQganVzdCBhIGNvdXBsZSBjb21tZW50cyB0byBhZGQ6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PiZndDsmbmJzcDsgQ2FuIFVwZGF0ZSBQcm9wb3NhbHMgYmUgaXNzdWVkIGJ5IGFueW9uZSBidXQg dGhlIG1lbWJlciBpdHNlbGY/IElmIHdlIHNheSB5ZXMsIHRoZSBhbmFseXNpcyB3aWxsIGJlIG1v cmUgc3RyYWlnaHQgZm9yd2FyZCwgYnV0IGl0IGlzIGFsc28gbW9yZSBsaW1pdGVkLiBJZiB3ZSBz YXkgbm8sIHRoZSBxdWVzdGlvbiByZW1haW5zIHdobyBjYW4NCiBpc3N1ZSB0aGVtLiBUaGV5IGNv dWxkIGJlIGlzc3VlZCBieSB0aGUgc2VydmVyIG9yIGFub3RoZXIgbWVtYmVyLiBSaWdodCBub3cg SSBkb27igJl0IHNlZSB3aHkgYW5vdGhlciBtZW1iZXIgc2hvdWxkIGJlIGFsbG93ZWQgdG8gZG8g c28sIGJ1dCBJIGNvdWxkIHRoaW5rIG9mIHJlYXNvbnMgd2h5IHRoZSBzZXJ2ZXIgc2hvdWxkIGJl IGFsbG93ZWQgdG8gZG8gc28gKG11bHRpLWRldmljZSBjb250ZXh0KS4gV2Ugc2hvdWxkIGFnYWlu IGJlIHZlcnkgY2FyZWZ1bA0KIHcuci50IHRoZSBnaG9zdCB1c2VyIHNjZW5hcmlvIGluIG9yZGVy IHRvIGF2b2lkIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZSBzZXJ2ZXIgY2FuIHNuZWFrIGluIGEg bWFsaWNpb3VzIHBhcnRpY2lwYW50IHRoYXQgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRvbid0IHNlZSBhIGdvb2Qg cmVhc29uIGZvciBhbnlvbmUgb3RoZXIgdGhhbiBhIGxlYWYtb3duZXIgdG8gZXZlciBpc3N1ZSBh biB1cGRhdGUgdG8gdGhhdCBsZWFmLiBJZiB3ZSB0cmVhdCBtdWx0aS1kZXZpY2UgYXMgYSBzcGVj aWFsIGNhc2Ugb2YgZ3JvdXAsIHRoZW4gdGhlIHNlcnZlciB3b3VsZCBhbHNvIG5vdCBuZWVkIHRv IGRvIHRoaXMNCiDigJMgaXQgY291bGQgaW5zdGVhZCBqdXN0IGlzc3VlIGFkZHMgYW5kIHJlbW92 ZXMgYXMgZGV2aWNlcyBjaGFuZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+Jmd0OyBTZXJ2ZXIgYWRkL3JlbW92ZSBpcyBpbXBvcnRhbnQgaW4gbWFueSBwcmFjdGlj YWwgdXNlIGNhc2VzOiB5b3UgYnV5IGEgbmV3IHBob25lIGFuZCBsb2cgaW47IHRoZSBzZXJ2ZXIg d2FudHMgdG8gcmVtb3ZlIHlvdXIgb2xkIHBob25lIGZyb20gYWxsIGdyb3VwcyBpdCdzIGluLCBh bmQgYWRkIHRoZSBuZXcgcGhvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRvIHN0cmVzcyB0aGlzIHBvaW50LCBzZXJ2ZXIt Y29udHJvbGxlZCBncm91cCBtZW1iZXJzaGlwIGlzIGEgcHJhY3RpY2FsIG5lY2Vzc2l0eSBpbiBt YW55IGNhc2VzLiBJIGNhbuKAmXQgdGhpbmsgb2YgYW55IHNpZ25pZmljYW50IG1lc3NhZ2luZyBz ZXJ2aWNlIHRoYXQgZG9lcyBub3QgYWxsb3cgYWNjb3VudCByZXNldHMsIGFuZCBJIGJlbGlldmUN CiB0aGUgbWFqb3JpdHkgd2lsbCBhbGxvdyBtdWx0aS1kZXZpY2UvZ3JvdXAgdGhyZWFkcyB0byBj b250aW51ZSB3aGVuIHRoaXMgaGFwcGVucy4gRm9yIGV4YW1wbGUsIG1lbWJlcnNoaXAgb2YgYSB0 aHJlYWQgaW4gTWVzc2VuZ2VyIGlzIGJhc2VkIG9uIHVzZXIgYWNjb3VudCByYXRoZXIgdGhhbiBk ZXZpY2Ug4oCTIGlmIGEgZGV2aWNlIGlzIGF0dGFjaGVkIHRvIGEgZ2l2ZW4gdXNlciBhY2NvdW50 LCB0aGVuIGl0IGlzIGluaGVyZW50bHkgaW4gYW55IHRocmVhZHMNCiB0aGF0IHRoaXMgdXNlciBh Y2NvdW50IGlzIGFsc28gaW4uIExvZ2dpbmcgaW50byBhbiBhY2NvdW50IGlzIG5vdCBhIGNyeXB0 b2dyYXBoaWMgcHJvY2VzcyBhdHRhY2hlZCB0byBzb21lIG90aGVyIGRldmljZSwgYnV0IGF1dGhl bnRpY2F0aW5nIHRvIGFuIG9ubGluZSBzZXJ2aWNlIChlLmcuIHVzZXJuYW1lICYjNDM7IHBhc3N3 b3JkKS4gSSBiZWxpZXZlIFdpcmUgZm9sbG93cyB0aGUgc2FtZSBtb2RlbC4gSW4gdGhpcyB3b3Js ZCwgYSBkZXZpY2Ugd2hpY2gNCiBsb2dzIGludG8gYW4gYWNjb3VudCBuZWVkcyB0byBiZSBhYmxl IHRvIG5vdCBvbmx5IHJlY2VpdmUgZnV0dXJlIG1lc3NhZ2VzIHRvIHRoYXQgYWNjb3VudOKAmXMg dGhyZWFkcyAod2hpY2ggY291bGQgYmUgYWNoaWV2ZWQgYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVs IHdpdGhvdXQgc2VydmVyLWFkZCksIGJ1dCBhbHNvIHRvIHNlbmQgbWVzc2FnZXMgdG8gYW55IG9m IHRoZXNlIHRocmVhZHMgKHBvdGVudGlhbGx5IGJlZm9yZSBhbnkgb3RoZXIgZGV2aWNlDQogaW4g dGhlIHRocmVhZCBoYXMgY29tZSBvbmxpbmUpIOKAkyB3aGljaCB3b3VsZCBiZSBtb3JlIGNoYWxs ZW5naW5nIHRvIGltcGxlbWVudCBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWwuIEZvciB0aGlzIHJl YXNvbiwgSeKAmWQgc3Ryb25nbHkgZmF2b3VyIHNlcnZlciBhZGQgaW4gdGhlIHByb3RvY29sLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPk1MUyAmbHQ7bWxzLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiBLYXRyaWVsIENvaG4tR29yZG9uICZsdDttZUBrYXRyaWVsLmNvLnVr Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIDMwIEF1Z3VzdCAyMDE5IGF0IDE3OjQxPGJy Pg0KPGI+VG86IDwvYj4mcXVvdDttbHNAaWV0Zi5vcmcmcXVvdDsgJmx0O21sc0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5DYzogPC9iPk1lc3NhZ2luZyBMYXllciBTZWN1cml0eSBXRyAmbHQ7bWxzQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW01MU10gUHJvcG9zYWw6IFByb3Bv c2FscyAod2FzOiBMYXppbmVzcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtn ZW9yZ2lhJnF1b3Q7LHNlcmlmIj5UaGlzIGFic3RyYWN0aW9uIHNlZW1zIHNlbnNpYmxlLiBTZXJ2 ZXIgYWRkL3JlbW92ZSBpcyBpbXBvcnRhbnQgaW4gbWFueSBwcmFjdGljYWwgdXNlIGNhc2VzOiB5 b3UgYnV5IGEgbmV3IHBob25lIGFuZCBsb2cgaW47IHRoZSBzZXJ2ZXIgd2FudHMgdG8gcmVtb3Zl IHlvdXIgb2xkIHBob25lIGZyb20gYWxsIGdyb3VwcyBpdCdzIGluLCBhbmQNCiBhZGQgdGhlIG5l dyBwaG9uZS4gU2luY2Ugd2Ugb2YgY291cnNlIGRvbid0IHdhbnQgdG8gZ2l2ZSB0aGUgc2VydmVy IHRoZSBhYmlsaXR5IHRvIGFjdHVhbGx5IGVmZmVjdCB0aGlzIGNoYW5nZSwgb25seSB0byBwcm9w b3NlIGl0LCBpdCBzZWVtcyB0byBtZSB0aGF0IHdlIGFscmVhZHkgbmVlZCBhIHdheSB0byBkaXNj b25uZWN0IHByb3Bvc2FscyBhbmQgY29tbWl0cyBhbnl3YXkuIE9uY2UgdGhhdCdzIHRoZSBjYXNl LCBpdCBkb2Vzbid0IHNlZW0NCiB0b28gYmlnIGEgbGVhcCB0byBjbGVhbmx5IGZhY3RvciBhbGwg b3BlcmF0aW9ucyBpbnRvIHRoYXQgc3RydWN0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+TXkgbWFpbiB3b3JyeSB3b3VsZCBiZSBj b21wbGljYXRpbmcgdGhlIGFuYWx5c2lzLiBIb3dldmVyLCBpdCBzZWVtcyBsaWtlIGlmIHRoZSBz ZXBhcmF0aW9uIGlzIGNsZWFuIGVub3VnaCB0aGVuIGl0IG1pZ2h0IG5vdCBhY3R1YWxseSBtYWtl IHRoZSBhbmFseXNpcyB0b28gYmFkLCBiZWNhdXNlIHRoZXJlIGlzIGEgY2xlYW4gcHJvcGVydHkN CiAodGhhdCBLYXJ0aGlrIGRlc2NyaWJlZCkgZm9yIGVhY2ggZXBvY2ggY2hhbmdlLiBTbywgb24g YmFsYW5jZSwgSSB0aGluayBJJ20gaW4gZmF2b3VyIG9mIHRoaXMgcHJvcG9zYWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj4tLWthdHJp ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVHVlLCAyNyBBdWcgMjAxOSwgYXQgNjoyMyBQTSwgS2FydGhpayBCaGFyZ2F2 YW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiIGlkPSJxdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZx dW90OyxzZXJpZiI+SGkgUmljaGFyZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIzIEF1ZyAy MDE5LCBhdCAxODo0OCwgUmljaGFyZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2 LnN4Ij5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Z2VvcmdpYSZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHRvIGNvbmZp cm0gSSB1bmRlcnN0YW5kLCB0aGUga2V5IGV4Y2hhbmdlIHByb3RvY29sIGluIHRoaXMgY29uY2Vw dGlvbiB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSwgYXQgZWFjaCBlcG9jaDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gS0VNIGEgc2VjcmV0 IHRvIHNvbWUgc2V0IG9mIHBlb3BsZSB3aG9tIHlvdSBiZWxpZXZlIHRvIGJlIHRoZSBjdXJyZW50 IG1lbWJlcnMgb2YgdGhlIGdyb3VwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4yLiBTZW5kIHRoYXQgS0VNJ2VkIHZhbHVlIG91dCB0byB0aGUgZ3Jv dXAgdG9nZXRoZXIgd2l0aCBhIGRlc2NyaXB0aW9uIG9mIHRoZSBjdXJyZW50IG1lbWJlcnNoaXA8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIEtE RiB0aGUgS0VNJ2VkIHNlY3JldCB0b2dldGhlciB3aXRoIHRoZSBwcmlvciBlcG9jaCBzZWNyZXQg dG8gZ2V0IHRoZSBuZXcgZXBvY2ggc2VjcmV0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBVc2UgdGhlIG5ldyBlcG9jaCBzZWNyZXQgdG8gZ2Vu ZXJhdGUgYSBjb25maXJtYXRpb24gb3ZlciB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgZ3JvdXA8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlcmUgdGhlIEtFTSBp biAoMSkgd291bGQgYmUgc29tZXRoaW5nIGxpa2UgVHJlZUtFTSBvciBqdXN0ICZxdW90O2VuY3J5 cHQgdG8gYSBsaXN0IG9mIHB1YmxpYyBrZXlzJnF1b3Q7LiZuYnNwOyBUaGVuIHRoZSBwcm9wb3Nh bHMgd291bGQganVzdCBiZSBhIHdheSBmb3IgcGVvcGxlIHRvIHN5bmMgdXAgb24gd2hvIHRoZSBj dXJyZW50IG1lbWJlcnMgb2YgdGhlIGdyb3VwIGFyZSAoYnkgbGVhZiBrZXkpLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBl c3NlbnRpYWxseSBjb3JyZWN0LCBvZiBjb3Vyc2Ugd2l0aCBhIGJ1bmNoIG9mIGRldGFpbHMgdG8g Z3VhcmFudGVlIHRoYXQgZXZlcnlvbmUgZ2V0cyB0aGUgc2FtZSBrZXlzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgcmVtYWlucyBtb3N0bHkg dW5jaGFuZ2VkIGZyb20gd2hhdCB3ZSBoYXZlIGN1cnJlbnRseS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IG1ham9yIHRoaW5nIEkgd291bGQgYmUgd29ycmllZCBhYm91dCBpbiBzdWNoIGEgc3BsaXQgaXMg aG93IGl0IHdvdWxkIGRlYWwgd2l0aCBhdXRob3JpdHkgb3ZlciBjaGFuZ2VzLCB3aGljaCBhZmZl Y3QgdGhlIGF1dGhlbnRpY2F0aW9uIHByb3BlcnRpZXMgb2YgdGhlIHByb3RvY29sLiZuYnNwOyBU aGUgY3VycmVudCBQcm9wb3NhbHMgcHJvcG9zYWwgbWFpbnRhaW5zIHRoZSBwcm9wZXJ0eSB0aGF0 IGV2ZXJ5b25lDQogYWdyZWVzIG9uIHRoZSBwcm9wb3NhbHMgYW5kIGNhbiB2ZXJpZnkgdGhhdCB0 aGV5IHdlcmUgcHJvcGVyLCBlLmcuLCBvbmx5IHRoZSBob2xkZXIgb2YgYSBsZWFmIGNhbiB1cGRh dGUgdGhhdCBsZWFmLiZuYnNwOyBJZiB3ZSBzZXZlciB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRo ZSBwcm9wb3NhbHMgYW5kIHRoZSB0b3AtbGV2ZWwgdHJhbnNjcmlwdCBlbnRpcmVseSwgdGhlbiBJ J20gbm90IHN1cmUgaG93IHlvdSB3b3VsZCBjb250aW51ZSB0byBhc3N1cmUNCiB0aGF0LCBzYXks IHRoZSBzZW5kZXIgb2YgYSBDb21taXQgZGlkbid0IGp1c3Qgc3dhcCBvdXQgSm9lJ3MgbGVhZiBr ZXkgZm9yIHRoZSBOU0EuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2hhbmdlcyB3 b3VsZCBiZSBzaWduZWQgYnkgdGhlIHNlbmRlciwgYXMgdXN1YWwuIFRoZSBvbmx5IHF1ZXN0aW9u IGlzIHdoZXRoZXIgdGhpcyBzaWduYXR1cmUgaXMgZW5vdWdoLCB3aXRob3V0IGJpbmRpbmcgdGhl IHNpZ25hdHVyZSB0byB0aGUga2V5IGV4Y2hhbmdlIHRyYW5zY3JpcHQgb3IgY3VycmVudCBlcG9j aCBzZWNyZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ob3RlIHRoYXQgdGhlIHRyZWUgc3luY2hyb25pemF0aW9uIHByb3RvY29sIGhhcyBpdHMg b3duIHRyYW5zY3JpcHQgb24gaG93IHRoZSB0cmVlIGhhcyBjaGFuZ2VkIG92ZXIgdGltZSwgYW5k IGNlcnRhaW5seSB3ZSBjb3VsZCByZXF1aXJlIGVhY2ggdXBkYXRlIHRvIHNpZ24gdGhpcyDigJxz dGF0ZSBoaXN0b3J54oCdIHRyYW5zY3JpcHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBzaG91bGQgb2YgY291cnNlIGltcG9zZSB0aGUgcmVx dWlyZW1lbnQgdGhhdCBvbmx5IHRoZSAmcXVvdDtob2xkZXIgb2YgdGhlIHNpZ25hdHVyZSBrZXkg Y29ycmVzcG9uZGluZyB0byBhIGxlYWbigJ0gY2FuIHVwZGF0ZSB0aGF0IGxlYWYuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBmYWN0LCB0aGUg dHJlZSB1cGRhdGUgcHJvdG9jb2wgY2FuIGVuc3VyZSB0aGF0IG9ubHkgbWVtYmVycyBvZiBhIHN1 YnRyZWUgY2FuIGNoYW5nZSB0aGUgcm9vdCBvZiB0aGF0IHN1YnRyZWUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdoYXQgd2UgZ3Vh cmFudGVlIG5vdyBhbnl3YXkuIEkgZG9u4oCZdCBzZWUgdGhhdCBzdWJzdGFudGlhbGx5IGNoYW5n aW5nIGluIHRoZSBkZWNvdXBsZWQgZGVzaWduLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Z2VvcmdpYSZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhh dCB0aGVyZSBpcyBkZWdyZWUgb2Ygc2VwYXJhdGlvbiBoZXJlIChzaW5jZSwgZS5nLiwgaXQncyBl YXN5IHRvIGltYWdpbmUgc3dhcHBpbmcgaW4gYSAmcXVvdDtsaXN0IG9mIGtleXMmcXVvdDsgS0VN IGZvciBUcmVlS0VNKS4mbmJzcDsgQnV0IGl0IHNlZW1zIGxpa2UgYSBmYWlybHkgaGlnaCBkZWdy ZWUgb2YgY291cGxpbmcgaXMgbmVjZXNzYXJ5IHRvIG1haW50YWluIGF1dGhlbnRpY2F0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIHdoYXQgd291bGQgYmUgdGhlIGF1dGhlbnRp Y2F0aW9uIHByb3BlcnR5IHlvdSB3b3VsZCB3YW50IGZvciBhIHRyZWUgY2hhbmdlPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRyZWUgY2hh bmdpbmcgc2VuZGVyIG11c3Qga25vdyB0aGUgc2lnbmF0dXJlIGtleSBmb3IgYSBtZW1iZXIgKmFu ZCBtdXN0IGFsc28ga25vdyB0aGUgY3VycmVudCBlcG9jaCBzZWNyZXQqPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBzIHdoYXQgeW91 IGFyZSBwb2ludGluZyBvdXQgaXMgdGhhdCB3ZSBjYW5ub3QgcmVtb3ZlIHNpZ25hdHVyZXMgZnJv bSB0aGUga2V5IGV4Y2hhbmdlIHByb3RvY29sLCBhbmQgc28gd2XigJlkIGVuZCB1cCBuZWVkaW5n IHR3byBzaWduYXR1cmVzOyBvbmUgZm9yIHRyZWUgc3luY2hyb25pemF0aW9uIGFuZCB0aGUgb3Ro ZXIgZm9yIGF1dGhlbnRpY2F0aW5nIHRoZSBrZXkgZXhjaGFuZ2UuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY3R1YWxseSwgd2UgYWxzbyBuZWVk IGEgdGhpcmQgc2lnbmF0dXJlIGZvciB0aGUgbWVzc2FnZSBwcm90ZWN0aW9uLiBIb3cgYW5kIHdo ZW4gd2UgY2FuIHNoYXJlIHRoZXNlIHNpZ25hdHVyZXMgaXMgYW4gb3B0aW1pemF0aW9uIHByb2Js ZW0sIGJ1dCB0aGV5IHNlcnZlIGRpZmZlcmVudCBwdXJwb3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LUthcnRoaWs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9y Z2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBdWcgMjMsIDIwMTkgYXQg MToyMiBQTSBLYXJ0aGlrIEJoYXJnYXZhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcnRoaWtleWFu LmJoYXJnYXZhbkBpbnJpYS5mciI+a2FydGhpa2V5YW4uYmhhcmdhdmFuQGlucmlhLmZyPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIEFsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPkl0IHNlZW1zIHRvIG1lIHRoYXQgb25lIHdheSB0 byB0aGluayBhYm91dCDigJxsYXppbmVzc+KAnSB3b3VsZCBiZSB0byBjbGVhbmx5IHNlcGFyYXRl IHRoZSBNTFMga2V5IGV4Y2hhbmdlIGludG8gdHdvIGRpZmZlcmVudCBwcm90b2NvbHMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGZpcnN0IGlzIGEg4oCcY2xhc3NpY+KAnSBhdXRoZW50aWNhdGVkIHN5bmNocm9uaXphdGlvbiBw cm90b2NvbCB3aGVyZSBtZW1iZXJzIG9mIGEgZ3JvdXAgY2FuIGNyZWF0ZSBhbmQgbW9kaWZ5IGEg c2hhcmVkIGRhdGEgc3RydWN0dXJlIChpbiB0aGlzIGNhc2UsIHRoZSBncm91cCBtZW1iZXJzaGlw IHRyZWUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHNlY29uZCBpcyBhIG5vdmVsIGtleSBlc3RhYmxpc2htZW50IHByb3RvY29sIHdoZXJl IHNvbWUgbWVtYmVyIG9mIHRoZSBncm91cCBnZW5lcmF0ZXMgYSBmcmVzaCBncm91cCBzZWNyZXQg dGhhdCB3aWxsIGJlIGRlbGl2ZXJlZCBvbmx5IHRvIHRoZSBjdXJyZW50IG1lbWJlcnMgY29tcHV0 ZWQgZnJvbSB0aGUgKGN1cnJlbnQpIGdyb3VwIHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3VycmVudGx5IHRoZSBmaXJzdCBhbmQgc2Vj b25kIHByb3RvY29scyBhcmUgdGlnaHRseSBpbnRlcmxlYXZlZDogZXZlcnkgdGltZSB0aGUgZ3Jv dXAgZGF0YSBzdHJ1Y3R1cmUgaXMgbW9kaWZpZWQgYnkgc29tZSBtZW1iZXIgKG9yIGFkbWluKSwg dGhhdCBtZW1iZXIgbXVzdCBhbHNvIGdlbmVyYXRlIGFuZCBkaXN0cmlidXRlIHRoZSBmcmVzaCBn cm91cCBzZWNyZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgbGF6aW5lc3MgcHJvcG9zYWwgY2FuIGJlIHRob3VnaHQgb2YgYXMgZGV0YWNo aW5nIHRoZSB0d28gcHJvdG9jb2xzOiB0aGUga2V5IGVzdGFibGlzaG1lbnQgcHJvdG9jb2wgY2Fu IGZvbGxvdyBncm91cCBtb2RpZmljYXRpb25zIHdpdGggc29tZSBkZWxheS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gcmF0aGVyIHRoYW4g dHJ5aW5nIHRvIGFkZCDigJxsYXppbmVzc+KAnSB0byB0aGUgZXhpc3RpbmcgcHJvdG9jb2wsIHNo b3VsZCB3ZSB0cnkgdG8gZG8gdGhpcyBkZXRhY2htZW50IGluIGEgcHJpbmNpcGxlZCB3YXkgYnkg ZGVmaW5pbmcgdHdvIGluZGVwZW5kZW50IHN1Yi1wcm90b2NvbHM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBoYXZlIHRoZSBhZHZh bnRhZ2UgdGhhdCB3ZSBtYXkgYmUgYWJsZSB0byBjb25zaWRlciBvdGhlciBkZXNpZ25zIGZvciBz eW5jaHJvbml6YXRpb24gYW5kIGtleSBlc3RhYmxpc2htZW50LCB3aGljaCBtYXkgd2VsbCBiZSBv cnRob2dvbmFsIGNvbmNlcm5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiBvdXIgbW9kZWwgb2YgTUxTLCB3ZSBjYW4gYWxyZWFkeSBmYWN0 b3Igb3V0IHRoZSBwcm90b2NvbCBpbiB0aGlzIHdheSwgYnV0IGl0IG1ha2VzIHRoZSBzZWN1cml0 eSBpbnZhcmlhbnRzIGEgYml0IGhhcmRlciB0byBleHByZXNzIGluIGEgdXNlci1mcmllbmRseSB3 YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T dGlsbCwgSSB3b3VsZCBwcmVmZXIgdG8gY29tcG9zZSBwcm9vZnMgZm9yIHNpbXBsZXIgc3ViLXBy b3RvY29scyByYXRoZXIgdGhhbiB0cnkgdG8gcHJvdmUgc2VjdXJpdHkgZm9yIGEgc2luZ2xlIGNv bXBsZXggcHJvdG9jb2wgd2l0aCBsb3RzIG9mIG9wdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tS2FydGhpazxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDIzIEF1ZyAyMDE5LCBhdCAxMDo0OCwgUmljaGFyZCBCYXJuZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2Li5zeCI+cmxiQGlwdi5zeDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+T24g RnJpLCBBdWcgMjMsIDIwMTkgYXQgMTA6MjEgQU0gU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVm PSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90 OyxzZXJpZiI+SGl5YSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+T24gMjMvMDgv MjAxOSAxNToxMCwgUmljaGFyZCBCYXJuZXMgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj4mZ3Q7PHNwYW4g Y2xhc3M9InF0LWdtYWlsLW0tODAzMTc2NzU3MzI5NDIwNjI2NGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+Jmd0OyBJJ20gbm90IGNsZWFyIG9uIHdoYXQg eW91IG1lYW4gYnkgJnF1b3Q7bWVhbmluZ2Z1bGx5IGhhbmRsZWQgYnkgbWVtYmVycyZxdW90Oy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEm cXVvdDssc2VyaWYiPiZndDs8c3BhbiBjbGFzcz0icXQtZ21haWwtbS04MDMxNzY3NTczMjk0MjA2 MjY0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3Jn aWEmcXVvdDssc2VyaWYiPkknbSBhc3N1bWluZyB0aGF0IE1MUyBwcm90b2NvbCBkYXRhIHdpbGwg bGlrZWx5IGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5oYW5kbGVkIGJ5IGEgbGlicmFyeS4gSVNUTSBtb3JlIGxp a2VseSB0aGF0IHN1Y2ggYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+bGlicmFyeSBtaWdodCBkZWZhdWx0IHRvLCBv ciBiZSBjYXJlbGVzc2x5IHVzZWQgdG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5ob25vciBhbnl0aGluZyB0aGUg c2VydmVyIHByb3Bvc2VzIGlmIHRoaXMgaXMgYW4gTUxTPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5wcm90b2NvbCBm ZWF0dXJlIHJhdGhlciB0aGFuIGFuIGFwcGxpY2F0aW9uIGxheWVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5mZWF0 dXJlLiBUaGF0J2QgYmUgYW4gZXhhbXBsZSBvZiBub3QgbWVhbmluZ2Z1bGx5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlm Ij5oYW5kbGluZyB0aGlzOi0pIFdlIGhhdmUgc2VlbiBzaW1pbGFyIGtpbmRzIG9mPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNl cmlmIj5mYWlsdXJlIHdpdGggYXBwbGljYXRpb25zIGFuZCBUTFMgbGlicmFyaWVzIGluIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZx dW90OyxzZXJpZiI+cGFzdCB3aGVyZSBjZXJ0cyBhcmVuJ3QgY2hlY2tlZCBldGMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp Y2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhIj5PaCBJIHNlZS4mbmJzcDsgVGhhdCB3b3VsZCBhY3R1YWxseSBiZSBhIHByZXR0eSBk aWZmaWN1bHQgcG9saWN5IHRvIGltcGxlbWVudCwgYXQgbGVhc3Qgd2l0aG91dCB0dXJuaW5nIG9m ZiBhdXRoZW50aWNhdGlvbiBhbHRvZ2V0aGVyLCBhdCBsZWFzdCBpbiB0aGUgZW52aXNpb25lZCBw cm90b2NvbC4mbmJzcDsgQnkgd2hpY2ggSSBtZWFuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+LSBSaWdodCBub3csIGNsaWVudHMgYXJl IGV4cGVjdGVkIHRvIG1haW50YWluIGEgbGlzdCBvZiBtZW1iZXJzJyBzaWduaW5nIGtleXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+LSBTbyBz aWduZXJzIGFyZSBqdXN0IGluZGljYXRlZCBieSB0aGVpciBpbmRleCBpbiB0aGF0IGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+LSBUaGUg b2J2aW91cyB3YXkgdG8gYWRkIG5vbi1tZW1iZXIgc2lnbmVycyBpcyB0byByZXNlcnZlIGEgYmxv Y2sgb2YgaW5kaWNlcyAoc2F5IDB4RkZGRkZGeHgpIHRoYXQgY2FuIGNvcnJlc3BvbmQgdG8gYXBw bGljYXRpb24tc3BlY2lmaWMgZW50aXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+LSBUaGVuIGNsaWVudHMgbmVlZCB0byBnZXQgY29uZmln dXJlZCB3aXRoIHdoaWNoIHNlcnZlciBrZXlzIGdvIHdpdGggd2hpY2ggcmVzZXJ2ZWQgaW5kaWNl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj YSI+QXNzdW1pbmcgd2UgZ28gaW4gdGhhdCBkaXJlY3Rpb24sIHRoZSBuYXR1cmFsLCAmcXVvdDtJ IGRvbid0IGNhcmUgYWJvdXQgc2VydmVyLWluaXRpYXRlZCBzdHVmZiZxdW90OyBsaWJyYXJ5IGRl c2lnbiB3b3VsZCBiZSB0byBqdXN0IG5vdCBpbXBsZW1lbnQgYW55IHNwZWNpYWwgaGFuZGxpbmcg Zm9yIHRob3NlIHJlc2VydmVkIGluZGljZXMsDQogaW4gd2hpY2ggY2FzZSB5b3UnbGwgcmVqZWN0 IGFueXRoaW5nIGZyb20gdGhlIHNlcnZlci4mbmJzcDsgSSB3b3VsZCBleHBlY3QgYSBsaWJyYXJ5 IHRoYXQgZG9lcyBhbnl0aGluZyBlbHNlIHRvIGhhdmUgYW4gQVBJIGZvciB0aGUgY29uZmlndXJh dGlvbiByZXF1aXJlZCBpbiB0aGUgbGFzdCBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoZSBvYnZpb3VzIHNjcmV3LXVwIGNh c2Ugd291bGQgYmUsICZxdW90O1RyZWF0IGEgc2lnbmF0dXJlIGZyb20gdGhlIHJlc2VydmVkIGJs b2NrIGFzIHRydXN0ZWQmcXVvdDsuJm5ic3A7IEJ1dCB0aGF0J3MgYWN0dWFsbHkgYSBsaXR0bGUg aGFyZCB0byBpbXBsZW1lbnQ7IGJlY2F1c2UgdGhlIHB1YmxpYyBrZXlzIGFyZW4ndCBwcm92aWRl ZCwgeW91DQogd291bGQgaGF2ZSB0byBhbHNvIG5vdCBkbyBhbnkgc2lnbmF0dXJlIHZlcmlmaWNh dGlvbiBhdCBhbGwsIHdoaWNoIG1lYW5zIHlvdSdyZSBub3cgdG90YWxseSBvcGVuIHRvIHRoZSB3 b3JsZC4mbmJzcDsgSG9wZWZ1bGx5IHRoYXQgd291bGQgcmFpc2Ugc29tZSByZWQgZmxhZ3MgZm9y IGRldmVsb3BlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI ZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhIj5TbyBpdCdzIG5vdCBpbXBvc3NpYmxlIHRvIHNjcmV3IHVwLCBidXQgbm90 IHRyaXZpYWwgZWl0aGVyLiZuYnNwOyBBdCBsZWFzdCBpZiB5b3Ugd2FudCB0byBtYWludGFpbiBh dXRoZW50aWNhdGlvbiBmb3IgZ3JvdXAgbWVtYmVycy4mbmJzcDsgSWYgeW91IHR1cm4gdGhhdCBv ZmYgdG9vLCBJIGRvbid0IHRoaW5rIHdlIGNhbiBzYXZlIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPi0tUmljaGFyZCZuYnNwOzxz cGFuIGNsYXNzPSJxdC1nbWFpbC1tLTgwMzE3Njc1NzMyOTQyMDYyNjRhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2Vv cmdpYSZxdW90OyxzZXJpZiI+SSBkbyBhY2NlcHQgdGhlIGFyZ3VtZW50IHRoYXQgaXQgY2FuIGhh cHBlbiBhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPmFwcGxpY2F0aW9uIGxheWVyIGlmIG5vdCBkZWZpbmVk IGluIHRoZSBNTFMgcHJvdG9jb2wsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5idXQgZG9pbmcgdGhpcyBraW5kIG9m IHRoaW5nIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+c2VlbXMgc2FmZXIg dG8gbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtn ZW9yZ2lhJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPkl0J3MgYWxzbyBub3QgY2xl YXIgdG8gbWUgdGhhdCBhbGwgTUxTIGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+d291bGQgbmVl ZCB0aGlzIGZlYXR1cmUuIChUaGF0IG1heSBiZSB0cnVlLCBJIGp1c3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPmRv bid0IGtub3cuKSBJZiB0aGV5IGRvbid0LCB0aGVuIGFnYWluLCBpdCBzZWVtcyB0bzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90Oyxz ZXJpZiI+YmUgbW9yZSBjb25zZXJ2YXRpdmUgdG8gbGVhdmUgaXQgdG8gYXBwbGljYXRpb25zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZx dW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5JIGFncmVlIHRoYXQgdGhlcmUgYXJlIHNo YXJwIGVkZ2VzIGhvd2V2ZXIgdGhpcyBraW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj5vZiB0aGluZyBpcyBkb25l IHRob3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+Q2hlZXJzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Z2VvcmdpYSZxdW90Oyxz ZXJpZiI+Uy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9InNp emUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJzaXplIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYSI+TUxTIG1haWxpbmcgbGlzdDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O2dlb3JnaWEmcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1b3Q7LHNlcmlmIj48YSBocmVmPSJtYWlsdG86TUxT QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYSI+TUxTQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Z2VvcmdpYSZxdW90OyxzZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19tbHMmYW1wO2Q9RHdNRmFRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9 TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZhbXA7bT1nYWJzZ0c1M09zUldKQ2h5Ym12QlBoUDRCd3c2 ZFJicmJ1cjlNWk1xU2JBJmFtcDtzPWpQZW4zdWhrSlN1Zy1YR1N0UVpnN3ZXbl95czFMZVhiWDVO d1FTMEN3Q2cmYW1wO2U9Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N TFMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NTFNAaWV0Zi5vcmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bWxzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtnZW9yZ2lhJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_46673A730D7342069DBE009CA8B4F9B5fbcom_-- From nobody Thu Sep 19 07:24:38 2019 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 BA81D120090 for ; Thu, 19 Sep 2019 07:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 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=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2vWCqqlc8oWd for ; Thu, 19 Sep 2019 07:24:33 -0700 (PDT) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 9483012000F for ; Thu, 19 Sep 2019 07:24:33 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id t84so2830928oih.10 for ; Thu, 19 Sep 2019 07:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JCGWVUIOVhYsatjKrxPIl1A4dZdxT9Icpiu8ZJTzomo=; b=dklERRT/AVFOn7AVXFa6T31GS1g8ZyJfP7hRCdNwULHUv7jAhWtkuS01NyAoMHN/Ty RYSXAxbFuiW4t4jQ+JuG4D0Y9Nud3D8xf5VxcjfIbNcr88IPuM5ZOuBWir1c//hn6OV9 iuce/enfha7xb022ooYG3DOU+FPuq9zx9nwKKS5PoUeiYLi34Ix1mbMjqY/WVep0IXkH IRGcQhrxICK7zUJyd7+RrkIIua6oX0/1lxm9xbuNSWK4CK3Oc/DswXKpiPO88SHEtpX8 Hi0v4hhEkPx85fum+wJ+p6jcmBP74ItfYvHEQz3bI5e/+JfVAU3qjOPV9rIDrenyIg9h a1+w== 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=JCGWVUIOVhYsatjKrxPIl1A4dZdxT9Icpiu8ZJTzomo=; b=ERZbO/mbSWp407HVJjEAhDYPsowxaGtDMi18Dii3dYaZogwzljdfeDV9Pe1YKaSCov qA23KLbduRKaAzLXubqn4b62V/gwE02JaILveFRaOzRa75UD56TrDGDu3nIP2rgtu+Fv OTtMbzpnVsY9aH7moCVU+6MUeOMQJ7IP5p/uMUMFBVeE6bYEszzKTNr10EUWDECQlm4C 7+kv+Lf/Hq7h6+TsSrI5y69wAF0+ondkdF9CFGd4/zX0EqFWos8cwip0p0FGmYk5oaes LiXmuMYHFkMuzXnRmRQX195SG6XCel5KyRLl2ITfVeJ0HPHFGIMzwbRJb5o/Gd1Mf4NO fM+g== X-Gm-Message-State: APjAAAWEck8f9Mf6WU3T21kl0M+lq0dAxa1EVGxHIBDBY6Rzu2mdjnEy NDfBnLm67O8uyRjC6OGBFaUEwWRsNpWHj5L0zzwdOQ== X-Google-Smtp-Source: APXvYqxf2ZCiXAJ7PHDqXiwbNeiR2cmhQzZVa68rj2rqxL2zeRdp/y2EDtlKkHNk4NAELFHY6UNZ1xTqeCzMO/9ndec= X-Received: by 2002:aca:4e12:: with SMTP id c18mr2258507oib.135.1568903072661; Thu, 19 Sep 2019 07:24:32 -0700 (PDT) MIME-Version: 1.0 References: <9d3f0d93-4f69-bb71-9951-f3007820b14d@cs.tcd.ie> <33917BCD-5C3C-4D04-A7AE-D9B0E9A9D010@wire.com> <752B7C91-19CF-45CF-8774-DED73A908A23@inria.fr> <9756C849-1248-4E2B-9509-07EAF59A0FC4@inria.fr> <6119dac1-2822-4756-b514-4bb500bbaf04@www.fastmail.com> <46673A73-0D73-4206-9DBE-009CA8B4F9B5@fb.com> In-Reply-To: <46673A73-0D73-4206-9DBE-009CA8B4F9B5@fb.com> From: Richard Barnes Date: Thu, 19 Sep 2019 10:24:19 -0400 Message-ID: To: Jon Millican Cc: "mls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000557cf60592e8b667" Archived-At: Subject: Re: [MLS] Proposal: Proposals (was: Laziness) X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 14:24:37 -0000 --000000000000557cf60592e8b667 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the current PR is pretty good w.r.t. these comments. W.r.t. Updates: "An Update proposal requests that the sender's leaf node in the tree be updated with a new HPKE public key." No affordance for Updates other than by the leaf holder. W.r.t. Server-initiated: That's not in this PR, but I think it lays the groundwork. In the sense that once Proposals are split out, the constraints on who can make a proposal can be looser than who can make a Commit. So for example, you could configure the application to accept Proposals from the server and include them in the next Commit. That takes care of server-initiated Remove completely. For server-initiated Add, you would also need a way for someone external to the group to send to the group, for the interim period in between Proposal/Add and Commit. But that seems like it can be handled in a future iteration. --Richard On Thu, Sep 19, 2019 at 10:00 AM Jon Millican wrote: > Sorry for jumping onto this thread quite late, but just a couple comments > to add: > > > > > Can Update Proposals be issued by anyone but the member itself? If we > say yes, the analysis will be more straight forward, but it is also more > limited. If we say no, the question remains who can issue them. They coul= d > be issued by the server or another member. Right now I don=E2=80=99t see = why > another member should be allowed to do so, but I could think of reasons w= hy > the server should be allowed to do so (multi-device context). We should > again be very careful w.r.t the ghost user scenario in order to avoid the > possibility that the server can sneak in a malicious participant that way= . > > > > I don't see a good reason for anyone other than a leaf-owner to ever issu= e > an update to that leaf. If we treat multi-device as a special case of > group, then the server would also not need to do this =E2=80=93 it could = instead > just issue adds and removes as devices change. > > > > > > > Server add/remove is important in many practical use cases: you buy a > new phone and log in; the server wants to remove your old phone from all > groups it's in, and add the new phone. > > > > To stress this point, server-controlled group membership is a practical > necessity in many cases. I can=E2=80=99t think of any significant messagi= ng service > that does not allow account resets, and I believe the majority will allow > multi-device/group threads to continue when this happens. For example, > membership of a thread in Messenger is based on user account rather than > device =E2=80=93 if a device is attached to a given user account, then it= is > inherently in any threads that this user account is also in. Logging into > an account is not a cryptographic process attached to some other device, > but authenticating to an online service (e.g. username + password). I > believe Wire follows the same model. In this world, a device which logs > into an account needs to be able to not only receive future messages to > that account=E2=80=99s threads (which could be achieved at the applicatio= n level > without server-add), but also to send messages to any of these threads > (potentially before any other device in the thread has come online) =E2= =80=93 which > would be more challenging to implement at the application level. For this > reason, I=E2=80=99d strongly favour server add in the protocol. > > > > Jon > > > > > > *From: *MLS on behalf of Katriel Cohn-Gordon < > me@katriel.co.uk> > *Date: *Friday, 30 August 2019 at 17:41 > *To: *"mls@ietf.org" > *Cc: *Messaging Layer Security WG > *Subject: *Re: [MLS] Proposal: Proposals (was: Laziness) > > > > This abstraction seems sensible. Server add/remove is important in many > practical use cases: you buy a new phone and log in; the server wants to > remove your old phone from all groups it's in, and add the new phone. Sin= ce > we of course don't want to give the server the ability to actually effect > this change, only to propose it, it seems to me that we already need a wa= y > to disconnect proposals and commits anyway. Once that's the case, it > doesn't seem too big a leap to cleanly factor all operations into that > structure. > > > > My main worry would be complicating the analysis. However, it seems like > if the separation is clean enough then it might not actually make the > analysis too bad, because there is a clean property (that Karthik > described) for each epoch change. So, on balance, I think I'm in favour o= f > this proposal. > > > > --katriel > > > > On Tue, 27 Aug 2019, at 6:23 PM, Karthik Bhargavan wrote: > > > > Hi Richard, > > > > On 23 Aug 2019, at 18:48, Richard Barnes wrote: > > > > Just to confirm I understand, the key exchange protocol in this conceptio= n > would be something like, at each epoch: > > > > 1. KEM a secret to some set of people whom you believe to be the current > members of the group > > 2. Send that KEM'ed value out to the group together with a description of > the current membership > > 3. KDF the KEM'ed secret together with the prior epoch secret to get the > new epoch secret > > 4. Use the new epoch secret to generate a confirmation over the current > state of the group > > Where the KEM in (1) would be something like TreeKEM or just "encrypt to = a > list of public keys". Then the proposals would just be a way for people = to > sync up on who the current members of the group are (by leaf key). > > > > This is essentially correct, of course with a bunch of details to > guarantee that everyone gets the same keys. > > It remains mostly unchanged from what we have currently. > > > > The major thing I would be worried about in such a split is how it would > deal with authority over changes, which affect the authentication > properties of the protocol. The current Proposals proposal maintains the > property that everyone agrees on the proposals and can verify that they > were proper, e.g., only the holder of a leaf can update that leaf. If we > sever the connection between the proposals and the top-level transcript > entirely, then I'm not sure how you would continue to assure that, say, t= he > sender of a Commit didn't just swap out Joe's leaf key for the NSA. > > > > The changes would be signed by the sender, as usual. The only question is > whether this signature is enough, without binding the signature to the ke= y > exchange transcript or current epoch secret. > > Note that the tree synchronization protocol has its own transcript on how > the tree has changed over time, and certainly we could require each updat= e > to sign this =E2=80=9Cstate history=E2=80=9D transcript. > > We should of course impose the requirement that only the "holder of the > signature key corresponding to a leaf=E2=80=9D can update that leaf. > > In fact, the tree update protocol can ensure that only members of a > subtree can change the root of that subtree. > > This is what we guarantee now anyway. I don=E2=80=99t see that substantia= lly > changing in the decoupled design. > > > > > > I agree that there is degree of separation here (since, e.g., it's easy t= o > imagine swapping in a "list of keys" KEM for TreeKEM). But it seems like= a > fairly high degree of coupling is necessary to maintain authentication. > > > > So, what would be the authentication property you would want for a tree > change? > > The tree changing sender must know the signature key for a member *and > must also know the current epoch secret*? > > > > Perhaps what you are pointing out is that we cannot remove signatures fro= m > the key exchange protocol, and so we=E2=80=99d end up needing two signatu= res; one > for tree synchronization and the other for authenticating the key exchang= e. > > Actually, we also need a third signature for the message protection. How > and when we can share these signatures is an optimization problem, but th= ey > serve different purposes. > > > > -Karthik > > > > > > --Richard > > > > > > > > On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan < > karthikeyan.bhargavan@inria.fr> wrote: > > Hello All, > > > > It seems to me that one way to think about =E2=80=9Claziness=E2=80=9D wou= ld be to cleanly > separate the MLS key exchange into two different protocols. > > The first is a =E2=80=9Cclassic=E2=80=9D authenticated synchronization pr= otocol where > members of a group can create and modify a shared data structure (in this > case, the group membership tree). > > The second is a novel key establishment protocol where some member of the > group generates a fresh group secret that will be delivered only to the > current members computed from the (current) group state. > > Currently the first and second protocols are tightly interleaved: every > time the group data structure is modified by some member (or admin), that > member must also generate and distribute the fresh group secret. > > The laziness proposal can be thought of as detaching the two protocols: > the key establishment protocol can follow group modifications with some > delay. > > > > So rather than trying to add =E2=80=9Claziness=E2=80=9D to the existing p= rotocol, should > we try to do this detachment in a principled way by defining two > independent sub-protocols? > > It would have the advantage that we may be able to consider other designs > for synchronization and key establishment, which may well be orthogonal > concerns. > > > > In our model of MLS, we can already factor out the protocol in this way, > but it makes the security invariants a bit harder to express in a > user-friendly way. > > Still, I would prefer to compose proofs for simpler sub-protocols rather > than try to prove security for a single complex protocol with lots of > options. > > > > Best, > > -Karthik > > > > > > On 23 Aug 2019, at 10:48, Richard Barnes > wrote= : > > > > > > > > On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > > > Hiya, > > > > On 23/08/2019 15:10, Richard Barnes wrote: > > > > > > I'm not clear on what you mean by "meaningfully handled by members". > > > > > > > I'm assuming that MLS protocol data will likely be > > handled by a library. ISTM more likely that such a > > library might default to, or be carelessly used to, > > honor anything the server proposes if this is an MLS > > protocol feature rather than an application layer > > feature. That'd be an example of not meaningfully > > handling this:-) We have seen similar kinds of > > failure with applications and TLS libraries in the > > past where certs aren't checked etc. > > > > Oh I see. That would actually be a pretty difficult policy to implement, > at least without turning off authentication altogether, at least in the > envisioned protocol. By which I mean: > > > > - Right now, clients are expected to maintain a list of members' signing > keys > > - So signers are just indicated by their index in that list > > - The obvious way to add non-member signers is to reserve a block of > indices (say 0xFFFFFFxx) that can correspond to application-specific > entities > > - Then clients need to get configured with which server keys go with whic= h > reserved indices > > > > Assuming we go in that direction, the natural, "I don't care about > server-initiated stuff" library design would be to just not implement any > special handling for those reserved indices, in which case you'll reject > anything from the server. I would expect a library that does anything el= se > to have an API for the configuration required in the last point. > > > > The obvious screw-up case would be, "Treat a signature from the reserved > block as trusted". But that's actually a little hard to implement; becau= se > the public keys aren't provided, you would have to also not do any > signature verification at all, which means you're now totally open to the > world. Hopefully that would raise some red flags for developers. > > > > So it's not impossible to screw up, but not trivial either. At least if > you want to maintain authentication for group members. If you turn that > off too, I don't think we can save you. > > > > --Richard > > > > > > > > I do accept the argument that it can happen at the > > application layer if not defined in the MLS protocol, > > but doing this kind of thing at the application layer > > seems safer to me. > > > > It's also not clear to me that all MLS applications > > would need this feature. (That may be true, I just > > don't know.) If they don't, then again, it seems to > > be more conservative to leave it to applications. > > > > I agree that there are sharp edges however this kind > > of thing is done though. > > > > Cheers, > > S. > > _______________________________________________ > > 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 > --000000000000557cf60592e8b667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the current PR is pretty good w.r.t. these co= mments.

W.r.t. Updates: "An Update proposal r= equests that the sender's leaf node in the tree be updated with a new H= PKE public key."=C2=A0 No affordance for Updates other than by the lea= f holder.

W.r.t. Server-initiated: That's = not in this PR, but I think it lays the groundwork.=C2=A0 In the sense that= once Proposals are split out, the constraints on who can make a proposal c= an be looser than who can make a Commit.=C2=A0 So for example, you could co= nfigure the application to accept Proposals from the server and include the= m in the next Commit.=C2=A0 That takes care of server-initiated Remove comp= letely.=C2=A0 For server-initiated Add, you would also need a way for someo= ne external to the group to send to the group, for the interim period in be= tween Proposal/Add and=C2=A0 Commit.=C2=A0 But that seems like it can be ha= ndled in a future iteration.

--Richard


On Thu, Sep 19, 2019 at 10:00 AM Jon Millican <jmillican@fb.com> wrote:

Sorry for jumping onto this thread quite late,= but just a couple comments to add:

=C2=A0

>=C2=A0 Can Update Proposals be issued by a= nyone but the member itself? If we say yes, the analysis will be more strai= ght forward, but it is also more limited. If we say no, the question remain= s who can issue them. They could be issued by the server or another member. Right no= w I don=E2=80=99t see why another member should be allowed to do so, but I = could think of reasons why the server should be allowed to do so (multi-dev= ice context). We should again be very careful w.r.t the ghost user scenario in order to avoid the possibility that the s= erver can sneak in a malicious participant that way.

=C2=A0

I don't see a good reason for anyone other= than a leaf-owner to ever issue an update to that leaf. If we treat multi-= device as a special case of group, then the server would also not need to d= o this =E2=80=93 it could instead just issue adds and removes as devices change.<= u>

=C2=A0

=C2=A0

> Server add/remove is important in many pr= actical use cases: you buy a new phone and log in; the server wants to remo= ve your old phone from all groups it's in, and add the new phone.

=C2=A0

To stress this point, server-controlled group = membership is a practical necessity in many cases. I can=E2=80=99t think of= any significant messaging service that does not allow account resets, and = I believe the majority will allow multi-device/group threads to continue when this h= appens. For example, membership of a thread in Messenger is based on user a= ccount rather than device =E2=80=93 if a device is attached to a given user= account, then it is inherently in any threads that this user account is also in. Logging into an account is not a crypto= graphic process attached to some other device, but authenticating to an onl= ine service (e.g. username + password). I believe Wire follows the same mod= el. In this world, a device which logs into an account needs to be able to not only receive future messages = to that account=E2=80=99s threads (which could be achieved at the applicati= on level without server-add), but also to send messages to any of these thr= eads (potentially before any other device in the thread has come online) =E2=80=93 which would be more challenging t= o implement at the application level. For this reason, I=E2=80=99d strongly= favour server add in the protocol.

=C2=A0

Jon

=C2=A0

=C2=A0

From: = MLS <mls-bounces@ietf.org> o= n behalf of Katriel Cohn-Gordon <me@katriel.co.uk>
Date: Friday, 30 August 2019 at 17:41
To: "mls@ietf= .org" <mls@ie= tf.org>
Cc: Messaging Layer Security WG <mls@ietf.org>
Subject: Re: [MLS] Proposal: Proposals (was: Laziness)=

=C2=A0

This abstraction seems sensible. Server add/remove is important in many p= ractical use cases: you buy a new phone and log in; the server wants to rem= ove your old phone from all groups it's in, and add the new phone. Since we of course don't want to give the server th= e ability to actually effect this change, only to propose it, it seems to m= e that we already need a way to disconnect proposals and commits anyway. On= ce that's the case, it doesn't seem too big a leap to cleanly factor all operations into that structure.

=C2=A0

My main worry would be complicating the analysis. However, it seems like = if the separation is clean enough then it might not actually make the analy= sis too bad, because there is a clean property (that Karthik described) for each epoch change. So, on balance, I think I&= #39;m in favour of this proposal.

=C2=A0

--katriel

=C2=A0

On Tue, 27 Aug 2019, at 6:23 PM, Karthik Bhargavan w= rote:

=C2=A0

Hi Richard,

=C2=A0

On 23 Aug 2019, at 18:48, Richard Barnes <rlb@ipv.sx> wrote:

=C2=A0

Just to confirm I understand, the key exchange proto= col in this conception would be something like, at each epoch:

=C2=A0

1. KEM a secret to some set of people whom you belie= ve to be the current members of the group

2. Send that KEM'ed value out to the group toget= her with a description of the current membership

3. KDF the KEM'ed secret together with the prior= epoch secret to get the new epoch secret

4. Use the new epoch secret to generate a confirmati= on over the current state of the group

Where the KEM in (1) would be something like TreeKEM= or just "encrypt to a list of public keys".=C2=A0 Then the propo= sals would just be a way for people to sync up on who the current members o= f the group are (by leaf key).

=C2=A0

This is essentially correct, of course with a bunch = of details to guarantee that everyone gets the same keys.

It remains mostly unchanged from what we have curren= tly.

=C2=A0

The major thing I would be worried about in such a s= plit is how it would deal with authority over changes, which affect the aut= hentication properties of the protocol.=C2=A0 The current Proposals proposa= l maintains the property that everyone agrees on the proposals and can verify that they were proper, e.g., only t= he holder of a leaf can update that leaf.=C2=A0 If we sever the connection = between the proposals and the top-level transcript entirely, then I'm n= ot sure how you would continue to assure that, say, the sender of a Commit didn't just swap out Joe's leaf = key for the NSA.

=C2=A0

The changes would be signed by the sender, as usual.= The only question is whether this signature is enough, without binding the= signature to the key exchange transcript or current epoch secret.

Note that the tree synchronization protocol has its = own transcript on how the tree has changed over time, and certainly we coul= d require each update to sign this =E2=80=9Cstate history=E2=80=9D transcri= pt.

We should of course impose the requirement that only= the "holder of the signature key corresponding to a leaf=E2=80=9D can= update that leaf.

In fact, the tree update protocol can ensure that on= ly members of a subtree can change the root of that subtree.<= /p>

This is what we guarantee now anyway. I don=E2=80=99= t see that substantially changing in the decoupled design.

=C2=A0

=C2=A0

I agree that there is degree of separation here (sin= ce, e.g., it's easy to imagine swapping in a "list of keys" K= EM for TreeKEM).=C2=A0 But it seems like a fairly high degree of coupling i= s necessary to maintain authentication.

=C2=A0

So, what would be the authentication property you wo= uld want for a tree change?

The tree changing sender must know the signature key= for a member *and must also know the current epoch secret*?<= /p>

=C2=A0

Perhaps what you are pointing out is that we cannot = remove signatures from the key exchange protocol, and so we=E2=80=99d end u= p needing two signatures; one for tree synchronization and the other for au= thenticating the key exchange.

Actually, we also need a third signature for the mes= sage protection. How and when we can share these signatures is an optimizat= ion problem, but they serve different purposes.

=C2=A0

-Karthik

=C2=A0

=C2=A0

--Richard

=C2=A0

=C2=A0

=C2=A0

On Fri, Aug 23, 2019 at 1:22 PM Karthik Bhargavan &l= t;karth= ikeyan.bhargavan@inria.fr> wrote:

Hello All,

=C2=A0

It seems to me that one way to think about =E2=80=9Claziness=E2=80=9D wou= ld be to cleanly separate the MLS key exchange into two different protocols= .

The first is a =E2=80=9Cclassic=E2=80=9D authenticat= ed synchronization protocol where members of a group can create and modify = a shared data structure (in this case, the group membership tree).

The second is a novel key establishment protocol whe= re some member of the group generates a fresh group secret that will be del= ivered only to the current members computed from the (current) group state.=

Currently the first and second protocols are tightly= interleaved: every time the group data structure is modified by some membe= r (or admin), that member must also generate and distribute the fresh group= secret.

The laziness proposal can be thought of as detaching= the two protocols: the key establishment protocol can follow group modific= ations with some delay.

=C2=A0

So rather than trying to add =E2=80=9Claziness=E2=80= =9D to the existing protocol, should we try to do this detachment in a prin= cipled way by defining two independent sub-protocols?

It would have the advantage that we may be able to c= onsider other designs for synchronization and key establishment, which may = well be orthogonal concerns.

=C2=A0

In our model of MLS, we can already factor out the p= rotocol in this way, but it makes the security invariants a bit harder to e= xpress in a user-friendly way.

Still, I would prefer to compose proofs for simpler = sub-protocols rather than try to prove security for a single complex protoc= ol with lots of options.

=C2=A0

Best,

-Karthik

=C2=A0

=C2=A0

On 23 Aug 2019, at 10:48, Richard Barnes <rlb@ipv.sx> wrote:<= u>

=C2=A0

=C2=A0

=C2=A0

= On Fri, Aug 23, 2019 at 10:21 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> = wrote:

=C2=A0

Hiya,

=C2=A0

On 23/08/2019 15:10, Richard Barnes wrote:

>=C2=A0

> I'm not clear on what you mean by "meaningful= ly handled by members".

>=C2=A0

=C2=A0

I'm assuming that MLS protocol data will likely be

handled by a library. ISTM more likely that such a

library might default to, or be carelessly used to,<= u>

honor anything the server proposes if this is an MLS=

protocol feature rather than an application layer=

feature. That'd be an example of not meaningfully

handling this:-) We have seen similar kinds of

failure with applications and TLS libraries in the

past where certs aren't checked etc.

= =C2=A0

= Oh I see.=C2=A0 That would actually be a pretty difficult policy to impleme= nt, at least without turning off authentication altogether, at least in the= envisioned protocol.=C2=A0 By which I mean:

= =C2=A0

= - Right now, clients are expected to maintain a list of members' signin= g keys

= - So signers are just indicated by their index in that list

= - The obvious way to add non-member signers is to reserve a block of indice= s (say 0xFFFFFFxx) that can correspond to application-specific entities<= /u>

= - Then clients need to get configured with which server keys go with which = reserved indices

= =C2=A0

= Assuming we go in that direction, the natural, "I don't care about= server-initiated stuff" library design would be to just not implement= any special handling for those reserved indices, in which case you'll reject anything from the server.=C2=A0 I would ex= pect a library that does anything else to have an API for the configuration= required in the last point.

= =C2=A0

= The obvious screw-up case would be, "Treat a signature from the reserv= ed block as trusted".=C2=A0 But that's actually a little hard to i= mplement; because the public keys aren't provided, you would have to also not do any signature verification at all, which means y= ou're now totally open to the world.=C2=A0 Hopefully that would raise s= ome red flags for developers.

= =C2=A0

= So it's not impossible to screw up, but not trivial either.=C2=A0 At le= ast if you want to maintain authentication for group members.=C2=A0 If you = turn that off too, I don't think we can save you.<= /p>

= =C2=A0

= --Richard=C2=A0=C2=A0

= =C2=A0

= =C2=A0

=C2=A0

I do accept the argument that it can happen at the

application layer if not defined in the MLS protocol,

but doing this kind of thing at the application layer

seems safer to me.

=C2=A0

It's also not clear to me that all MLS applications<= /u>

would need this feature. (That may be true, I just

don't know.) If they don't, then again, it seems to=

be more conservative to leave it to applications.=

=C2=A0

I agree that there are sharp edges however this kind=

of thing is done though.

=C2=A0

Cheers,

S.

_____________________________= __________________

MLS mailing list

_______________________________________________

MLS mailing list

=C2=A0

=C2=A0

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--000000000000557cf60592e8b667-- From nobody Tue Sep 24 13:51:42 2019 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 1C233120071 for ; Tue, 24 Sep 2019 13:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.999 X-Spam-Level: X-Spam-Status: No, score=-16.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 8_G9reRcB9SR for ; Tue, 24 Sep 2019 13:51:37 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 303B8120020 for ; Tue, 24 Sep 2019 13:51:37 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id r5so3913396qtd.0 for ; Tue, 24 Sep 2019 13:51:37 -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=EMOsc6KWOpKWABoZcHAipCx2a87piy6sOv5GhfpA4Rc=; b=Z/R+A6u3KbeGgCzoFoLyzKIBPvSLZeXBx1X5z9u4zCabtnRAAh0NBM6816y1SXpcp7 4KmR6J55Hk9KyjYAS+SBU9dUOrmX9YXWVLAvAVqTNlGlWsX/4K/23FZ1BR77UqXBPTsv WxNw37pRbgZ1WI1IMWUuVvbiOdlm7bxK2tzuY8XZgoTGG88X/PwnmgA7cQqJRJMc6mMK yhdgAveYziCTx9ikzzZayYgCmb1viM4aek1SABd8vXUhO6yG9HvNekZNJRDzXlRZW7tO qV5ZGS/mrxXjWGc7zevjOjlcUQ1BoHdvlavFEuGTKMhAl4qH8n+gRwgmRI0bX12MOrG/ QY/g== 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=EMOsc6KWOpKWABoZcHAipCx2a87piy6sOv5GhfpA4Rc=; b=h/aozyqiR7gvIIGo2cxVn568snWE83od2RGSwT8DXhJ3nUgf3cifVmwo5qPL7DzV0A 0wm0b4pJoRKBlNUwCpnNHeFXIEmtYYuLpuvazvN5CgkA6+pWsqfEiD8tTOiGOSwJxwAI SfOEogqucFMSlK0YhmpMybu0sVk/8/1lL2FGsYPMj6s/FZ9J1pH4dxZIXbLjgIQ1VWZ7 rrxv2rTE1huXrJk+aZT9d8ekpcRrskkHNDj4tFkTNKEecKfi/ImsP95YfaeA8CKdIr5T WuJ8B/xHgWut2qUXFfj8z9hz/XUDHm1JrTZOv9xNFP9wtQNTyPtJlTnM5BbVImrijbd6 gn/Q== X-Gm-Message-State: APjAAAUM02GS2FN4p+2bEI+KVlved1kSYXrYJ0CIkzNIMjv50gOE9LER plpViNFMw/b2n6S5e5+2KehANm8ADYlYybScMN8Xlw== X-Google-Smtp-Source: APXvYqyMfZzvZeC78jddT8abBkmYHD74m82Ew2GnAEGSO/2m8Xz/MTu7mpakPCP4zXZTUVq7R6KSVQq264+n3U4yAlw= X-Received: by 2002:aed:2902:: with SMTP id s2mr4965465qtd.205.1569358295956; Tue, 24 Sep 2019 13:51:35 -0700 (PDT) MIME-Version: 1.0 References: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org> In-Reply-To: From: Peter Slatala Date: Tue, 24 Sep 2019 13:51:10 -0700 Message-ID: To: Jon Callas Cc: Messaging Layer Security WG , Benjamin Beurdouche Content-Type: multipart/alternative; boundary="000000000000c1e163059352b30f" Archived-At: Subject: Re: [MLS] AEAD data in messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 20:51:40 -0000 --000000000000c1e163059352b30f Content-Type: text/plain; charset="UTF-8" Hello, I haven't heard back from anyone. Please let me know if there is interest, and if so, what's the best way to continue this discussion. Peter On Mon, Sep 16, 2019 at 1:54 PM Peter Slatala wrote: > Thanks Benjamin, Jon & Jeff for the discussion so far. > > I have wrote made a tiny proposal ( > https://github.com/mlswg/mls-protocol/pull/208 ) to add AAD. It doesn't > look like the spec is the place to discuss possible applications or > tradeoffs, so we can do it in a pull request :) > > Let me know what's the best way to proceed here (discussion in the pull > request? interim? continuing in the email thread?) > > Looking forward to your comments and suggestions, > Peter > > On Sat, Aug 17, 2019 at 4:58 PM Jon Callas wrote: > >> >> >> On Aug 15, 2019, at 9:03 AM, Peter Slatala wrote: >> >> Thanks Jon! This is a lot of good feedback. As you mentioned, a lot of >> this AAD can be addressed by a separate edge-to-service key; what we >> optimize for here is message overhead. Overhead is less of a concern for >> messaging (unlike for real-time media), so it may be fine to have TLS + >> edge-to-service + encrypted message itself. The quirk is that some of the >> metadata would then have to be repeated in both delivery service encrypted >> message & e2ee encrypted message, which is what I wanted to optimize. By >> putting the info in AAD & using TLS we essentially save overhead (from >> duplicating data, and from extra encryption overhead to the server). >> >> I'll think about it more and see if I can come up with a reasonable >> proposal, but I am afraid I won't be able to come up with a solution that >> will address all of your concerns. >> >> >> Come up with the proposal. >> >> In general, I'm not opposed to features. Features are good and features >> are bad. Too few makes a system brittle, too many makes it hard to assess >> overall security and might introduce problems. >> >> Putting in a feature ought to do one of two things: enable something that >> is reasonable for someone to do, but no one is doing it yet (future >> expansion) or to head off a potential problem. >> >> On its surface, putting in AEAD doesn't sound bad, but we should avoid a >> situation where when Alice sends a message to Bob, there's something in >> there that is not directly relevant to that. A server in the middle ideally >> is just routing cipher text that is interpreted when Bob gets it, or is a >> message from Alice to the server. You gave lots of examples of things Alice >> might want to say to the server. I think it's a bad idea to conflate those >> into a single message. I also think it's a bad idea to have plaintext >> metadata in a message. A server can be compromised in subtle ways, like >> exceptional access, and making the protocol access-ready with metadata >> seems suboptimal. >> >> Without an obvious upside to an AEAD message -- meaning something that >> the AAD does that can't be done another way, my intuition is to leave it >> out. We have scenarios that are downside, with no obvious upside, so the >> risk calculus says to leave it out in my thinking. >> >> Obviously, with a use case for the AAD, that changes. That means >> describing something where the AAD permits us to do X that we couldn't do >> any other way. >> >> >> > Actually the header encryption exists to protect MLS metadata from the >> delivery service, so ideally most systems should deploy it. >> When you say header encryption, what exactly do you mean? (I don't >> believe draft mentions this). >> >> >> I searched through this thread, and I haven't found where I said "header >> encryption." The first mention is from Jeff Burdges; perhaps he's the best >> one to define it. >> >> Jon >> >> >> --000000000000c1e163059352b30f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I haven't heard back from anyone. Please le= t me know if there is interest, and if so, what's the best way to conti= nue this discussion.

Peter

On Mon, Sep 16, 20= 19 at 1:54 PM Peter Slatala <ps= la+mls@google.com> wrote:
Thanks Benjamin, Jon & Jeff for the d= iscussion so far.

I have wrote made a tiny proposal (=C2= =A0https://github.com/mlswg/mls-protocol/pull/208=C2=A0) to add AAD. = It doesn't look like the spec is the place to discuss possible applicat= ions or tradeoffs, so we can do it in a pull request :)

Let me know what's the best way to proceed here (discussion in th= e pull request? interim? continuing in the email thread?)

Looking forward to your comments and suggestions,
Peter

On Sat, Aug 17, 2019 at 4:58 PM Jon Callas <jon@callas.org> wrote:


On Aug 15, 2019, at 9:03 AM, Peter Slatala <psla+mls@google.com> wr= ote:

Thanks Jon! This is a = lot of good feedback. As you mentioned, a lot of this AAD can be addressed = by a separate edge-to-service key; what we optimize for here is message ove= rhead. Overhead is less of a concern for messaging (unlike for real-time me= dia), so it may be fine to have TLS=C2=A0+<= /a> edge-to-service=C2=A0+ encrypted message itself. The quirk is that some= of the metadata would then have to be repeated in both delivery service en= crypted message & e2ee encrypted message, which is what I wanted to opt= imize. By putting the info in AAD & using TLS we essentially save overh= ead (from duplicating data, and from extra encryption overhead to the serve= r).




=

On its surface, putting in AEAD doesn't sound bad, = but we should avoid a situation where when Alice sends a message to Bob, th= ere's something in there that is not directly relevant to that. A serve= r in the middle ideally is just routing cipher text that is interpreted whe= n Bob gets it, or is a message from Alice to the server. You gave lots of e= xamples of things Alice might want to say to the server. I think it's a= bad idea to conflate those into a single message. I also think it's a = bad idea to have plaintext metadata in a message. A server can be compromis= ed in subtle ways, like exceptional access, and making the protocol access-= ready with metadata seems suboptimal.

Without an o= bvious upside to an AEAD message -- meaning something that the AAD does tha= t can't be done another way, my intuition is to leave it out. We have s= cenarios that are downside, with no obvious upside, so the risk calculus sa= ys to leave it out in my thinking.

Obviously, with= a use case for the AAD, that changes. That means describing something wher= e the AAD permits us to do X that we couldn't do any other way.

> = Actually the header encryption exists to protect=C2=A0MLS=C2= =A0metadata from the delivery service, so ideally most systems should deplo= y it.
When you say header encryption, what exactly do you mean? (= I don't believe draft mentions this).



=
--000000000000c1e163059352b30f-- From nobody Fri Sep 27 10:14:10 2019 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 05C2B1209FD for ; Fri, 27 Sep 2019 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=cloudflare.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 ih62GnnK7kQ6 for ; Fri, 27 Sep 2019 10:14:06 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 A0181120849 for ; Fri, 27 Sep 2019 10:14:06 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id d66so1380056vka.2 for ; Fri, 27 Sep 2019 10:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=58hiHaoLbwhVgPbMU56riSdkKDOgmYEeY+yuW5KDvzA=; b=JTOZ92LdFf8XWFlLk+AgdBP5g4UhHXM0xJ9j1ZIrdrlCTrtCzNLavDGoGjxBwIFmZC +pE9w+XgoRUGK4wv1Ml+kNfbbdU84w203P/c+AGMhHoruV5/VdXf3AaQnXqlpiu2xyoO hiH2qIDHB6T6KA+X+Yhn7jSX938mD7McPV2ww= 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=58hiHaoLbwhVgPbMU56riSdkKDOgmYEeY+yuW5KDvzA=; b=mIBuCGDx9Lczs7Qw15/EohtpQSgaJkP9THlG9NpdxRZy7JIn/sHPpUQDebwSI7EIgV HNO/t7XxdOpKDi7hThD2eeYJsYqWc2HZzc+QhqZ2jB9iXii+L3nT9zetUycfay73+nlI uD+xqX9TFo64t1W/7CNjDBOzLJE0aTgcrGlMN5B0kHwioC3YojWXdHMA3lESzsOWKoIu gVWW8DCE0uTgdnydbzmZlAC4dynYB7FWynqDE8Q+nqN32CnYB73QihdKhRWq7zpOts3j KlFrT9PMihlDBQ9dWZBnAA+a55Kz3nq1Myo081wXOwz8b7LnU81UGuPGJS/oWldHINZ8 iv7A== X-Gm-Message-State: APjAAAVFkJAT0brodqOerygg74ae9B2wnyjyndaizlXIZMEtSy8IZEQl VxuJ7wJaxr0DsZK1fLQKracqFUqiDzoZvnegflSyOJyTteUJjsCx X-Google-Smtp-Source: APXvYqyhs87HratCfdv0dJzkj9XaoxikOU6j/VXBQX0wq3zSyBxhIoz1Nuq4S65E//krOxAYE40I/AR1V6mZzEuXdE0= X-Received: by 2002:a1f:da45:: with SMTP id r66mr4832796vkg.36.1569604445317; Fri, 27 Sep 2019 10:14:05 -0700 (PDT) MIME-Version: 1.0 References: <928256A6-1C12-4C62-BB8E-8E883AA00DA9@sn3rd.com> In-Reply-To: <928256A6-1C12-4C62-BB8E-8E883AA00DA9@sn3rd.com> From: Nick Sullivan Date: Fri, 27 Sep 2019 18:13:49 +0100 Message-ID: To: Sean Turner Cc: Messaging Layer Security WG Content-Type: multipart/alternative; boundary="00000000000066ea1405938c0325" Archived-At: Subject: Re: [MLS] October 2019 Interim Registration and Issue discussion X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 17:14:09 -0000 --00000000000066ea1405938c0325 Content-Type: text/plain; charset="UTF-8" MLSWG members, We have closed the registration for the interim next Tuesday and Wednesday at Cloudflare London (County Hall, South Bank, London). Information about the event is available on the Github page (https://github.com/mlswg/wg-materials/tree/master/interim-2019-10) and we will be following up with the registrants with specifics. If you missed the registration deadline and still want to attend, please contact the chairs. Nick & Sean On Thu, Aug 29, 2019 at 6:51 PM Sean Turner wrote: > The date and location are set for the October 2019 Interim meeting. It > will be on October 1st and 2nd at Cloudflare's London Office. More details > can be found on Github: > https://github.com/mlswg/wg-materials/tree/master/interim-2019-10. > > Please register with the following form if you intend on attending either > remotely or in person. > Registration Link (https://forms.gle/FAB8jUpLXo6tmaC58) > > Registration deadline closes on October 13th. > > We are soliciting proposals for presentations to add to the agenda for the > meeting. Please send proposals to mls-chairs@ietf.org. Due to time > limitations, these should be restricted to discussions about current active > drafts. > > Here are the active documents: > Protocol (https://datatracker.ietf.org/doc/draft-ietf-mls-protocol/) > Issues: https://github.com/mlswg/mls-protocol/issues > > Architecture ( > https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/) > Issues: https://github.com/mlswg/mls-architecture > > Federation https://datatracker.ietf.org/doc/draft-omara-mls-federation/) > Issues: https://github.com/mlswg/mls-federation/issues > > > We encourage the authors and other participants to read these issues, > distill the main questions raised by them and propose answers for > discussion on the list in the coming weeks. > > > Nick and Sean > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --00000000000066ea1405938c0325 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If you missed the registration deadline and still want to= =C2=A0attend, please contact the chairs.

Nick &= ; Sean

On Thu, Aug 29, 2019 at 6:51 PM Sean Turner <sean@sn3rd.com> wrote:
The date and location are set for the Octo= ber 2019 Interim meeting. It will be on October 1st and 2nd at Cloudflare&#= 39;s London Office. More details can be found on Github: https://github.com/mlswg/wg-materials/tree/master/int= erim-2019-10.

Please register with the following form if you intend on attending either r= emotely or in person.
Registration Link (https://forms.gle/FAB8jUpLXo6tmaC58)

Registration deadline closes on October 13th.

We are soliciting proposals for presentations to add to the agenda for the = meeting. Please send proposals to mls-chairs@ietf.org. Due to time limitations, these sho= uld be restricted to discussions about current active drafts.

Here are the active documents:
Protocol (https://datatracker.ietf.org/doc/= draft-ietf-mls-protocol/)
Issues: https://github.com/mlswg/mls-protocol/issues=

Architecture (https://datatracker.ietf.= org/doc/draft-ietf-mls-architecture/)
Issues: https://github.com/mlswg/mls-architecture

Federation https://datatracker.ietf.org/= doc/draft-omara-mls-federation/)
Issues: https://github.com/mlswg/mls-federation/issues=


We encourage the authors and other participants to read these issues, disti= ll the main questions raised by them and propose answers for discussion on = the list in the coming weeks.


Nick and Sean
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--00000000000066ea1405938c0325-- From nobody Mon Sep 30 02:11:05 2019 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 2A52612013C for ; Mon, 30 Sep 2019 02:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 keIBDPFbPPKV for ; Mon, 30 Sep 2019 02:11:01 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 0AA5B120046 for ; Mon, 30 Sep 2019 02:11:00 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id k20so10479778oih.3 for ; Mon, 30 Sep 2019 02:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zr1Sgv/7dwaYODSIsN3Ga3Nxrmd/MCNrFRIz6BLXaaE=; b=j+dslfu+IZR/WtJhoOfEHczdTsTIOERrt0+dOGAxxbiIt3iJn3pLGcSinDPQe6+Bwh lmxZtqX6ejoZBGnfhw4YF4p4X7rUsSNVaW1Ydblwe0p7GpBKAcQ5OAE42yOeetvKYdHE p1ENDEvYGYjveE6Ajf8xcCiBr9Ij9WWBL5k2RYe8GkMr+zHoAaz+/gH2Tlw20OTd6oi0 E6SDh+Zy2ZNtMMZXjZD5/8EvU9W2KYht40ITsfeGYJZCyCM8xXXBHe9lTYFBVdF9xgd0 PCwfVEYPxJAYyIR16pQjAtuvbwCjMLwCWMtqJHyNEA5/zWvb2lHkkdjVWDN8aqGSbsjJ lCzQ== 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=zr1Sgv/7dwaYODSIsN3Ga3Nxrmd/MCNrFRIz6BLXaaE=; b=fLY80D5CsNndSbQumF2rFxjVaxYX5LnzZNY24gyTOm6xyH8SvnBikQkjJQQDyCbp58 6CFECvUy9pujG7dtCmmTSzUN1uZOo2YTHiVYTRABhF2Wra703ZIfwEOXIk+ktxUGw4u6 lNnJJzbCMee1dGgBNqJ5dfnIWICyeiFVfifpGE+NWBtYh+ucYK55V0FIPzrYUwyZ1Th7 m9p7o2cbtDq1QYmccgWddYI55YYVuJxgj1vZ1A2twoZUnEEGQrUWXD6U77vM6TGPT62S 362SE01tCIY8YffDG7qnmLwlAe3nwWD9ZERKQdW5T/j9Q3gdtpSsCB9v1zKfxCI4Kixx 7iAw== X-Gm-Message-State: APjAAAXeTPBs9HXtWVZOIDAln256Fc4TfszYIq/Hr5PVaJGmkQgsGDHR DOj6kF874dC5A3g7i/7YlLnV+Dfu42DYC3kdrfu6kQ== X-Google-Smtp-Source: APXvYqz4iUJ1E5cgY02JFlKoAeD5vAELbjRp0f40ISPv6UZZ5jo/9F7ENKsZ8NIAWPcG5NhqzZtNEXtjjz1ynob7mCw= X-Received: by 2002:aca:cc0b:: with SMTP id c11mr16676040oig.169.1569834660025; Mon, 30 Sep 2019 02:11:00 -0700 (PDT) MIME-Version: 1.0 References: <7CF29B43-771F-4362-8320-6C934ADE61C7@callas.org> In-Reply-To: From: Richard Barnes Date: Mon, 30 Sep 2019 11:10:38 +0200 Message-ID: To: Peter Slatala Cc: Jon Callas , Messaging Layer Security WG , Benjamin Beurdouche Content-Type: multipart/alternative; boundary="0000000000004469360593c19d75" Archived-At: Subject: Re: [MLS] AEAD data in messages X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2019 09:11:03 -0000 --0000000000004469360593c19d75 Content-Type: text/plain; charset="UTF-8" Hey Peter, Sorry for the delay. I took a look at the PR. It seems like a reasonable starting point. Going back to the security analysis: It seems like this field serves a fairly niche case -- it basically makes the client's communication with the DS accountable to the rest of the group. To take Jon's slightly paranoid example, if someone is going to leak the keys through this vector, they have to tell the rest of the group about it. On the one hand, that seems to argue for putting the authenticated data under the *signature* on the message, rather than just as AAD. That way, it's attributable to an individual device (you know who's leaking the keys). On the other hand, the group can't rely on this mechanism being used for communications with the DS (the keys can always be leaked out of band w.r.t. MLS), so the accountability that this mechanism might seem to provide is trivially circumvented. Net of all that, ISTM that the best argument for this is the "SRTP case", where there's some utility to exposing some stuff to the DS, but you still want it authenticated E2E, in order to grant the DS the least privilege needed. That has been the state of the art with SRTP forever, and it has the risks that Jon notes. I would also note that there is some incipient work on carrying RTP over QUIC [1], which would erase even that authenticated header information. So I guess where I'm at is, "Eh, if people are excited about it, sure; but seems low value to me". I'm not seeing a killer app. --Richard [1] https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01 On Tue, Sep 24, 2019 at 10:51 PM Peter Slatala wrote: > Hello, > I haven't heard back from anyone. Please let me know if there is interest, > and if so, what's the best way to continue this discussion. > > Peter > > On Mon, Sep 16, 2019 at 1:54 PM Peter Slatala wrote: > >> Thanks Benjamin, Jon & Jeff for the discussion so far. >> >> I have wrote made a tiny proposal ( >> https://github.com/mlswg/mls-protocol/pull/208 ) to add AAD. It doesn't >> look like the spec is the place to discuss possible applications or >> tradeoffs, so we can do it in a pull request :) >> >> Let me know what's the best way to proceed here (discussion in the pull >> request? interim? continuing in the email thread?) >> >> Looking forward to your comments and suggestions, >> Peter >> >> On Sat, Aug 17, 2019 at 4:58 PM Jon Callas wrote: >> >>> >>> >>> On Aug 15, 2019, at 9:03 AM, Peter Slatala wrote: >>> >>> Thanks Jon! This is a lot of good feedback. As you mentioned, a lot of >>> this AAD can be addressed by a separate edge-to-service key; what we >>> optimize for here is message overhead. Overhead is less of a concern for >>> messaging (unlike for real-time media), so it may be fine to have TLS + >>> edge-to-service + encrypted message itself. The quirk is that some of the >>> metadata would then have to be repeated in both delivery service encrypted >>> message & e2ee encrypted message, which is what I wanted to optimize. By >>> putting the info in AAD & using TLS we essentially save overhead (from >>> duplicating data, and from extra encryption overhead to the server). >>> >>> I'll think about it more and see if I can come up with a reasonable >>> proposal, but I am afraid I won't be able to come up with a solution that >>> will address all of your concerns. >>> >>> >>> Come up with the proposal. >>> >>> In general, I'm not opposed to features. Features are good and features >>> are bad. Too few makes a system brittle, too many makes it hard to assess >>> overall security and might introduce problems. >>> >>> Putting in a feature ought to do one of two things: enable something >>> that is reasonable for someone to do, but no one is doing it yet (future >>> expansion) or to head off a potential problem. >>> >>> On its surface, putting in AEAD doesn't sound bad, but we should avoid a >>> situation where when Alice sends a message to Bob, there's something in >>> there that is not directly relevant to that. A server in the middle ideally >>> is just routing cipher text that is interpreted when Bob gets it, or is a >>> message from Alice to the server. You gave lots of examples of things Alice >>> might want to say to the server. I think it's a bad idea to conflate those >>> into a single message. I also think it's a bad idea to have plaintext >>> metadata in a message. A server can be compromised in subtle ways, like >>> exceptional access, and making the protocol access-ready with metadata >>> seems suboptimal. >>> >>> Without an obvious upside to an AEAD message -- meaning something that >>> the AAD does that can't be done another way, my intuition is to leave it >>> out. We have scenarios that are downside, with no obvious upside, so the >>> risk calculus says to leave it out in my thinking. >>> >>> Obviously, with a use case for the AAD, that changes. That means >>> describing something where the AAD permits us to do X that we couldn't do >>> any other way. >>> >>> >>> > Actually the header encryption exists to protect MLS metadata from >>> the delivery service, so ideally most systems should deploy it. >>> When you say header encryption, what exactly do you mean? (I don't >>> believe draft mentions this). >>> >>> >>> I searched through this thread, and I haven't found where I said "header >>> encryption." The first mention is from Jeff Burdges; perhaps he's the best >>> one to define it. >>> >>> Jon >>> >>> >>> _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000004469360593c19d75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Peter,

Sorry for the del= ay.

I took a look at the PR.=C2=A0 It seems like a= reasonable starting point.

Going back to the= security analysis: It seems like this field serves a fairly niche case -- = it basically makes the client's communication with the DS accountable t= o the rest of the group.=C2=A0 To take Jon's slightly paranoid example,= if someone is going to leak the keys through this vector, they have to tel= l the rest of the group about it.=C2=A0

On th= e one hand, that seems to argue for putting the authenticated data under th= e *signature* on the message, rather than just as AAD.=C2=A0 That way, it&#= 39;s attributable to an individual device (you know who's leaking the k= eys).=C2=A0 On the other hand, the group can't rely on this mechanism b= eing used for communications with the DS (the keys can always be leaked out= of band w.r.t. MLS), so the accountability that this mechanism might seem = to provide is trivially circumvented.

Net of = all that, ISTM that the best argument for this is the "SRTP case"= , where there's some utility to exposing some stuff to the DS, but you = still want it authenticated E2E, in order to grant the DS the least privile= ge needed.=C2=A0 That has been the state of the art with SRTP forever, and = it has the risks that Jon notes.=C2=A0 I would also note that there is some= incipient work on carrying RTP over QUIC [1], which would erase even that = authenticated header information.

So I guess where= I'm at is, "Eh, if people are excited about it, sure; but seems l= ow value to me".=C2=A0 I'm not seeing a killer app.
=
--Richard


[1] = https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-01
<= div>


On Tue, Sep 24, 2019 at 10:51 PM Peter Slatal= a <psla=3D2Bmls=3D40googl= e.com@dmarc.ietf.org> wrote:
Hello,
I haven't heard back fr= om anyone. Please let me know if there is interest, and if so, what's t= he best way to continue this discussion.

Peter

On Mon, Sep 16, 2019 at 1:54 PM Peter Slatala <psla+mls@google.com> wrote:
<= /div>
Tha= nks Benjamin, Jon & Jeff for the discussion so far.

= I have wrote made a tiny proposal (=C2=A0https://github.com/mlswg/mls-pro= tocol/pull/208=C2=A0) to add AAD. It doesn't look like the spec is = the place to discuss possible applications or tradeoffs, so we can do it in= a pull request :)

Let me know what's the best= way to proceed here (discussion in the pull request? interim? continuing i= n the email thread?)

Looking forward to your comme= nts and suggestions,
Peter

On Sat, Aug 17, 2019 at 4:58 PM J= on Callas <jon@calla= s.org> wrote:


On Aug 15, 2019, at 9= :03 AM, Peter Slatala <psla+mls@google.com> wrote:

<= div dir=3D"ltr">Thanks Jon! This is a lot of good feedback. As you mentione= d, a lot of this AAD can be addressed by a separate edge-to-service key; wh= at we optimize for here is message overhead. Overhead is less of a concern = for messaging (unlike for real-time media), so it may be fine to have TLS= =C2=A0+ edg= e-to-service=C2=A0+ encrypted message itself. The quirk is that some of the= metadata would then have to be repeated in both delivery service encrypted= message & e2ee encrypted message, which is what I wanted to optimize. = By putting the info in AAD & using TLS we essentially save overhead (fr= om duplicating data, and from extra encryption overhead to the server).

I'll think about it more and see if I= can come up with a reasonable proposal, but I am afraid I won't be abl= e to come up with a solution that will address all of your concerns.
<= /div>

Come up with the proposal.=C2= =A0

In general, I'm not opposed to features. F= eatures are good and features are bad. Too few makes a system brittle, too = many makes it hard to assess overall security and might introduce problems.=

Putting in a feature ought to do one of two thing= s: enable something that is reasonable for someone to do, but no one is doi= ng it yet (future expansion) or to head off a potential problem.
=
On its surface, putting in AEAD doesn't sound bad, but w= e should avoid a situation where when Alice sends a message to Bob, there&#= 39;s something in there that is not directly relevant to that. A server in = the middle ideally is just routing cipher text that is interpreted when Bob= gets it, or is a message from Alice to the server. You gave lots of exampl= es of things Alice might want to say to the server. I think it's a bad = idea to conflate those into a single message. I also think it's a bad i= dea to have plaintext metadata in a message. A server can be compromised in= subtle ways, like exceptional access, and making the protocol access-ready= with metadata seems suboptimal.

Without an obviou= s upside to an AEAD message -- meaning something that the AAD does that can= 't be done another way, my intuition is to leave it out. We have scenar= ios that are downside, with no obvious upside, so the risk calculus says to= leave it out in my thinking.

Obviously, with a us= e case for the AAD, that changes. That means describing something where the= AAD permits us to do X that we couldn't do any other way.


> Actua= lly the header encryption exists to protect=C2=A0MLS=C2=A0meta= data from the delivery service, so ideally most systems should deploy it.
When you say header encryption, what exactly do you mean? (I don&#= 39;t believe draft mentions this).

=
I searched through this thread, and I haven't found where I said &= quot;header encryption." The first mention is from Jeff Burdges; perha= ps he's the best one to define it.

Jon


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