From nobody Thu Mar 1 01:28:45 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C40F12D87A for ; Thu, 1 Mar 2018 01:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHECGq9NKcP6 for ; Thu, 1 Mar 2018 01:28:41 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 0D0A012D86A for ; Thu, 1 Mar 2018 01:28:41 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id i80so7796571lfg.5 for ; Thu, 01 Mar 2018 01:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LuSCDp00GSkRaUyLsx1xWJHCLG7/QkTVJyyjmMNL1/M=; b=E3B90XUup9qkyeOmXrKapWnVYIkcl1r1gmMUnuJO1oXWJ0kHSPRZ53CwLPuAULXfcm coDQxwuNrjFxK6wHUH6x/ovMEGgiqU0NUONDHbrbqdRGrqdDT3F6ZaeNFUrY6l3bQDVb W9j+G7k0ashlpvHvJ23pnAGv+UGlUSmU0dX8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LuSCDp00GSkRaUyLsx1xWJHCLG7/QkTVJyyjmMNL1/M=; b=LsHgV/s+p/WB4LEziIeKopdFuVzYrjtGCMQEkF34SKTvHMU0zOh8ODJNlwy5B6cQHQ K3ccS4kyO8yf5E/+B8N3uBYBnte46Wa6G2vdxWFBohdM2Csp6E0yGDrGvasDYH320TUQ NyeurBRFdl+yq4gUrPSXo5IIroFDh+yFvCwQrCPC1snBmaaaYx2n8f8Z40wVcBRVMW65 rNOgfUx0reP+iAcCLZ8H8yGnOj9W6/0Gp95y1JarOX2/frEOUCRbh98QcQ8xfOK+4z5O f+yxxsmnZJ7N5hU+lBkcgpRpjAcMm3wWWNOun4zfp005uKDkE1aoiZhYjZDuKoVkeNuT 92Ng== X-Gm-Message-State: AElRT7GJEwXtJtBythAFUo9s7z1teMh5g3YK0CD8eXI3b+FKu5DLDgbU Qm8LSz4F21RErIw1M6C/nvWO3bIfGeJHp8RtjYWyM06D X-Google-Smtp-Source: AG47ELuDOhcVkdJ9vhcI1G1XRbCEKiHyBwAUFwASY+zk8MsgLvDhDzKXDnSrDw9mJ4SosWZi1ZPAlK3w6EXp7UYeDos= X-Received: by 10.46.82.157 with SMTP id n29mr884011lje.145.1519896519216; Thu, 01 Mar 2018 01:28:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Thu, 1 Mar 2018 01:28:38 -0800 (PST) In-Reply-To: <7a138a3d-0889-59b4-2d20-c7acd1caab98@cs.tcd.ie> References: <7a138a3d-0889-59b4-2d20-c7acd1caab98@cs.tcd.ie> From: Dave Cridland Date: Thu, 1 Mar 2018 09:28:38 +0000 Message-ID: To: Stephen Farrell Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 09:28:43 -0000 On 1 March 2018 at 00:06, Stephen Farrell wrote: > > Hiya, > > On 28/02/18 22:56, Dave Cridland wrote: >> On 28 February 2018 at 21:16, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> On 28/02/18 17:14, Dave Cridland wrote: >>>> Given the latter, for example, I could not use an MLS-based system to >>>> discuss a tax problem with the authority, and since I'm unlikely to >>>> have a SAKKE-based messaging client, I'm unlikely to have encrypted >>>> messaging to my tax authority at all - which seems signficantly worse >>>> than merely having no Forward Secrecy. >>> >>> Sorry, why is transport layer security not sufficient between you >>> and your tax authority? >>> >> >> Because it's not a single hop. >> >> Supposing my tax authority uses XMPP, for example, and so has (in my >> case) hmrc.gov.uk as an XMPP domain. I use some commercialish XMPP >> provider. I don't want my provider to be able to read my tax messages, >> nor do I want them archived in plaintext on the server (although I >> probably do want a verifiable record). Meanwhile, HMRC wants to keep >> an archived, but secured, copy at their end, viewable by their >> organisation. > > I see no evidence that revenue.ie would ever prefer to handle > tax information via any intermediary when they have the option > to provide a URL to a tax payer or their agent. In the specific case of tax, no - or at least not yet. But the notion of saying that we want to encourage a plethora of random messaging tools delivered over the web while preventing a single interoperable platform doesn't appeal to me at all. Currently, however, there is the Secure Chorus consortium who are looking at SAKKE-based IBE over XMPP (they already do this for voice via MIKEY SAKKE) for offline-escrow based text messaging along government supply chains and within blue light. That's very much a real concept. SAKKE is absolutely useless for consumer-grade communications, of course - just as FS is entirely incompatible with the security goals for these markets. What I'd like to explore - rather than discard out of hand - is whether a framework can be used to negotiate between consumer-grade and government/enterprise/etc. > But perhaps you > do have a convincing use-case along those lines. If so, then I'd > say describing that, rather than asking to back off from forward > secrecy, might be a better approach at this stage (even if your > concern is really with the FS aspects of current MLS proposals). > >> >>> I'm unclear as to why the security guarantees (aimed for) between >>> groups of people ought be reduced in order to meet the goals of >>> securing communications between a person and a service provider. >>> >> >> I'm not suggesting they should be. > > FWIW, that's how I read your message. Apologies if I misread it. > >> >> I am suggesting that it might be nice if my options were not simply FS or FO. > > FO? > The O stands for Off, if that helps. Perhaps "FS or FA" might be more apropos? :-) >> >> (Besides which, the archives in a non-FS situation gain some security >> guarantees, too). > > Again, specifics there would be useful. I can't evaluate the > sentence above. > Archives in a non-FS situation can maintain integrity and authentication. In principle, archived FS messages provide this, but since they cannot be decrypted, the value of these properties is questionable at best. >> >>> I do agree that it'd be good if a user of some application could >>> add a new device and still see old messages, but I'm not at all >>> clear that's that significant (for the crypto) since people will >>> always need to have some kind of fallback to handle cases where >>> they've lost state. >> >> Assume a FS-only message transfer. In that case, how do we recover >> missing messages? > > I've no idea. But MLS isn't aiming to provide interoperable messaging > (sadly but understandably IMO), so that seem a tad out of scope, as > ekr pointed out. > That's lovely, but I am intending on writing a specification on MLS over XMPP, and so have some actual practical concerns (and no freedom to just write a complete IM protocol from scratch even if I wanted to). >> We have to transport those from another device that >> has them. That's a perfectly reasonable concept, and one that has been >> tried before in Skype. Unfortunately, as mobile devices replaced >> desktop/laptop combinations as the dominant device, they switched away >> from the design back to centrally-held archives since the clever >> synchronisation options simply didn't work. > > I'm fine if MLS is only usable by some subset of interpersonal > messaging applications myself, even if the precise delineation of > the set of applications that can use MLS isn't precisely known. > (So long as there are a useful set of applications that can use > MLS.) > So you're happy for the protocol to be useful only in theory. I'm rather more concerned with practise. I have an existing, widely-deployed, messaging protocol. It's used by consumers, government, military, finance, and so on. I would love to be able to provide the best security I can to the widest possible subset of those markets. I'm not fine if MLS is only usable by consumers. It will annoy me if MLS also degrades user experience to the point where users just turn it off, too. >> >> Of course, there are users who prefer the trade-off of higher security >> and no (or limited) archives. Such users would, one hopes, be warned >> about the change in security should they enter into a conversation >> with someone who cannot (or will not) support FS. > > I don't think such subtle differences are at all desirable myself. > > Cheers, > S. > >> >> Dave. >> From nobody Thu Mar 1 01:35:38 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9A12DA40 for ; Thu, 1 Mar 2018 01:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj_FEuAFXa45 for ; Thu, 1 Mar 2018 01:35:35 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 7895E12D86A for ; Thu, 1 Mar 2018 01:35:35 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id t204so7808433lff.9 for ; Thu, 01 Mar 2018 01:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ntYC2j9rXYY3E8Ho1/qbPeTpZQDtSlVzUO9Ak17XaDw=; b=eh32YyWYnFYcdyNZMEhJVsY0UDuCRHvLiA9sbVb53lUs8uXEoEa0Y+SxlnXMrEJ3VJ Cj+w19PaNHhYOE3LaK259jQpOE9Wz/mvgATAVeihRCsp1ytoj0b5ilCU76sqRZcjLdvo wryj2ZKNeGVOqprJBheqY5CbScxdaiYAFm0fA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ntYC2j9rXYY3E8Ho1/qbPeTpZQDtSlVzUO9Ak17XaDw=; b=snBKGN8bHqe8WQ79WP6+DN4GLYVpsDP+3f9ycB8C+BNWuCsmXVSu+nFZphkJvRLfBY XTXvhx/w525izpsfVQkwnhrGwB/GUUzAVBaIcJ5JSa9en2/Jk7N7eYx0LJskL8Ga0eJL XLThZGi+ZAbqKjZiH8x3UU9kZHcVYGlAaRHGGty52tAQ/ONEF1Iq7IexDsn5kX38ZrSc N/0lpA+S1kADTAbtBKBXEvyHBHFUVFX3Jlwwlfog18SIbkQo6FQB5KIYoGffgRSTE03r 9+V7e3nPkF53SDnZaX4pV2VaMSQkbGnVYkv34Zz0zAvJOjHIr3eQk24MQxgD3tPR4Q76 L1Ew== X-Gm-Message-State: AElRT7Hmybn7QvTbFxmYL5EiNpzgrPljV0l0fz43JE8DcjHxdIBynYq7 C4VKxVM0QjTilWJot4xKgjKtvcjz8zUozyyqH2SlJw== X-Google-Smtp-Source: AG47ELuqciF4ih0Q/ypJ46gbsNyt0rrGHSwQ0UrEf8ByFk2TXU/BiHXbiHCTrGp/uLYTLZ4ehhGZNUleFxlJXAFKZh8= X-Received: by 10.25.228.18 with SMTP id b18mr876985lfh.61.1519896933565; Thu, 01 Mar 2018 01:35:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Thu, 1 Mar 2018 01:35:33 -0800 (PST) In-Reply-To: <20180228234104.14fde460@T-200> References: <20180228222800.0a978ded@T-200> <20180228234104.14fde460@T-200> From: Dave Cridland Date: Thu, 1 Mar 2018 09:35:33 +0000 Message-ID: To: Dennis Jackson Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 09:35:37 -0000 On 28 February 2018 at 23:41, Dennis Jackson wrote: > The discussion on PFS has been done to death, both on the TLS mailing > list and in numerous other places and I would hate to see us repeat it > for little gain. In the end, TLS 1.3 mandates that PFS be used in > every connection. I find it hard to imagine that MLS will aspire > to a weaker security goal than TLS, but as you say, it is for the > group to decide. FWIW, I'm assuming that communication security will always have FS. That's highly desirable in all the markets I work in, although some don't use TLS to provide it. So I assume that MLS operates over links secured by TLS (or equivalent). However, when your protocol is being used to, for example, coordinate blue light, or MEDEVAC, or whatever, then the integrity of the archived communications turns out to be quite important. Dave. From nobody Thu Mar 1 02:42:22 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979FC12DA4F for ; Thu, 1 Mar 2018 02:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=c69EN/Sy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QDtWa1aN 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 bsRUwGc8PF4W for ; Thu, 1 Mar 2018 02:42:17 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0AC1276AF for ; Thu, 1 Mar 2018 02:42:17 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9703B20D4E; Thu, 1 Mar 2018 05:42:16 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Thu, 01 Mar 2018 05:42:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=/n96+g5AbWEMrOnJbp1jrTTccG 2iQ2W4ngj9KG3pQHs=; b=c69EN/Syu5ogIwqxSYZVIgYoU58POBHp25FOU+Hq3I a5CMl5RkwyPKi1/35xQDfQaEl2K6Cz+qvVCdE8kprkUhQcKU9OzAJjyOTI5WmltG tO2uf+orokIWFKi3j3uf6mcytWESSJQMLflzLRPx7dBq/X62nspt3nVP0e2VwTRh Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=/n96+g 5AbWEMrOnJbp1jrTTccG2iQ2W4ngj9KG3pQHs=; b=QDtWa1aNYc3R4xC6H8DHy/ f/1XJGA6a3CB7x210OohNOG6KDChmp9wvAGoOGOXy8W181pscrrnuapmawcxZZXy c/jI7tBy4Ji/PgbzhVdzhujnx+addmC5H7IjD2UDIDm5JjRSTWZpASU/9YAidJsS Jlf4CI2m9aNaKDJUyjBHEwI3X1eq/k4eAdpqPBtWi8zLA0FoM8UJfW/8h4Fd7Ugl hGveAGXTcLF34VJzRNBjFvLFnqpjyuqzC4W+PM1BF6THKGML595KQmSydBBd9sgL Dq5Tdnv+z0t1cd2kkpD7dkw2vy+9osEIfN2mWgjI0s4RcoV2xzzpXe5OQOOclSLQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 696469E4E4; Thu, 1 Mar 2018 05:42:16 -0500 (EST) Message-Id: <1519900936.1252177.1287608280.18488F31@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: "Phillip Hallam-Baker" , mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_151990093612521770" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 In-Reply-To: Date: Thu, 01 Mar 2018 10:42:16 +0000 References: Archived-At: Subject: Re: [MLS] A different way to do key exchange X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 10:42:21 -0000 This is a multi-part message in MIME format. --_----------=_151990093612521770 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi, Thanks for the comment! The two party protocol you describe is pretty close to MQV, and the three party version is fairly close to Burmester- Desmedt though with authentication in the exponent. The challenge here is that to compute that three-way key in the obvious manner, you need to do a round robin among all participants: A broadcasts a value, then B raises it to their private key and rebroadcasts it, then C and so on. This unfortunately doesn't work if any party is offline. We tried for a little while to figure out a way to make BD asynchronous, but without much success. It'd be great if we could though! K On Wed, 28 Feb 2018, at 10:50 PM, Phillip Hallam-Baker wrote: > Traditional TLS uses RSA Encryption and RSA signature to perform a key > exchange. Then we do a Diffie Hellman exchange. And if we want client > side authentication, well blerghhh> > > Why not just to a DH exchange? > > let Alice's {private, public} key be {a, A}, Bob's be {b, B} etc. > > A = g^a mod p > B = g^b mod p > etc > > Assume we have a directory that maps Alice->A, Bob->B etc. > > So using straight DH with mutual authentication, the mutually agreed > key is g^ab mod p. We calculate that as A^b mod p or B^a mod p.> > [From this point on, I will drop the mod p] > > This works, but it is not great because now all messages Alice sends > to Bob are encrypted under a single key. Yuk. We also have the problem > that they can be decrypted using Alice's key which she might not want.> > If Alice doesn't need to authenticate herself to Bob, she can just > generate a per-message ephemeral {x, X} and use that instead. The > mutual agreed key is now g^xb. Alice uses a different x each time. And > she can only decrypt the message if she decides to explicitly create a > decryption blob for herself.> > We could use this last exchange plus a HKDF key derivation for TLS > with the same properties as the original RSA exchange but more simply. > It does not give us PFS though, What if we want to get that with one > exchange?> > > To get PFS, we are going to need to introduce some sort of nonce or > blinding factor on Bob's side. So lets generate another keypair {y, Y} > and this time we are going to ADD it to Bob's key so that the key > agreement value is g^x(b+y).> > Alice knows x and calculates B^x . Y^x > Bob knows b, y and calculates either X^(b+y) or X^b . X^y > > At this point we are applying Torben Pedersen's Distributed key > generation scheme. And it has wondrous properties. We can perform all > the operations on b in a HSM and perform the blinding factor > calculation at the application level. We can even split the private > key between MULTIPLE HSMs.> > [OK I did elide something here, you can add b+y in modular arithmetic, > yes. But it is modulo the subgroup size not the prime. This is p-1 for > DH and (p-1)/8 for our CFRG curves.]> > > OK so now what if we want to perform client side authentication and > involve Alice's credential {a, A} ?> > Easy, the key agreement value is now g^(a+x)(b+y) > > > So here we have one key agreement function that lets us add in or > remove PFS according to whether or not we require it for a particular > set of messages. We can even turn PFS on in the middle of an existing > conversation or turn it off just by dropping the blinding factor out > of the mix (or not).> > Want three way key agreement? g^(a+x)(b+y)(c+z) > > Want it in ECC? yes, it all works in Ed25519 or Ed448. It will also > work in Curve 25519 and Curve 448 if someone can point me to a routine > to perform addition of two Montgomery points in the compressed > representation.> > > The HSM compartmentalization could be a way to defeat the Spectre and > Meltdown attacks. I showed some of this in a preview of my RSA talk > on this.> > All I need is for the CPU manufacturer to provide us with an isolated > core to perform x25519 and x448 operations. The information from that > core can then be used to apply a blinding factor to crypto operations > at the application level.> > > There is a simple proof that this approach is secure if the underlying > DH scheme is.> > _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls --_----------=_151990093612521770 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi,

Thanks for the comment! The two party protocol you describe is pretty close to MQV, and the three party version is fairly close to Burmester-Desmedt though with authentication in the exponent.

The challenge here is that to compute that three-way key in the obvious manner, you need to do a round robin among all participants: A broadcasts a value, then B raises it to their private key and rebroadcasts it, then C and so on. This unfortunately doesn't work if any party is offline. We tried for a little while to figure out a way to make BD asynchronous, but without much success. It'd be great if we could though!

K

On Wed, 28 Feb 2018, at 10:50 PM, Phillip Hallam-Baker wrote:
Traditional TLS uses RSA Encryption and RSA signature to perform a key exchange. Then we do a Diffie Hellman exchange. And if we want client side authentication, well blerghhh


Why not just to a DH exchange?

let Alice's {private, public} key be {a, A}, Bob's be {b, B} etc.

A = g^a mod p
B = g^b mod p
etc

Assume we have a directory that maps Alice->A, Bob->B etc.

So using straight DH with mutual authentication, the mutually agreed key is g^ab mod p. We calculate that as A^b mod p or B^a mod p.

[From this point on, I will drop the mod p]

This works, but it is not great because now all messages Alice sends to Bob are encrypted under a single key. Yuk. We also have the problem that they can be decrypted using Alice's key which she might not want.

If Alice doesn't need to authenticate herself to Bob, she can just generate a per-message ephemeral {x, X} and use that instead. The mutual agreed key is now g^xb. Alice uses a different x each time. And she can only decrypt the message if she decides to explicitly create a decryption blob for herself.

We could use this last exchange plus a HKDF key derivation for TLS with the same properties as the original RSA exchange but more simply. It does not give us PFS though, What if we want to get that with one exchange?


To get PFS, we are going to need to introduce some sort of nonce or blinding factor on Bob's side. So lets generate another keypair {y, Y} and this time we are going to ADD it to Bob's key so that the key agreement value is g^x(b+y).

Alice knows x and calculates B^x . Y^x
Bob knows b, y and calculates either X^(b+y) or X^b . X^y

At this point we are applying Torben Pedersen's Distributed key generation scheme. And it has wondrous properties. We can perform all the operations on b in a HSM and perform the blinding factor calculation at the application level. We can even split the private key between MULTIPLE HSMs.

[OK I did elide something here, you can add b+y in modular arithmetic, yes. But it is modulo the subgroup size not the prime. This is p-1 for DH and (p-1)/8 for our CFRG curves.]


OK so now what if we want to perform client side authentication and involve Alice's credential {a, A} ?

Easy, the key agreement value is now g^(a+x)(b+y)


So here we have one key agreement function that lets us add in or remove PFS according to whether or not we require it for a particular set of messages. We can even turn PFS on in the middle of an existing conversation or turn it off just by dropping the blinding factor out of the mix (or not).

Want three way key agreement?  g^(a+x)(b+y)(c+z)

Want it in ECC? yes, it all works in Ed25519 or Ed448. It will also work in Curve 25519 and Curve 448 if someone can point me to a routine to perform addition of two Montgomery points in the compressed representation.


The HSM compartmentalization could be a way to defeat the Spectre and Meltdown attacks. I showed some of this in a preview of my RSA talk on this.

All I need is for the CPU manufacturer to provide us with an isolated core to perform x25519 and x448 operations. The information from that core can then be used to apply a blinding factor to crypto operations at the application level. 


There is a simple proof that this approach is secure if the underlying DH scheme is. 

_______________________________________________
MLS mailing list

--_----------=_151990093612521770-- From nobody Thu Mar 1 05:16:06 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21112E86D for ; Thu, 1 Mar 2018 05:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SivsHjLcYqKj for ; Thu, 1 Mar 2018 05:15:57 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 C8FDF127735 for ; Thu, 1 Mar 2018 05:15:54 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id c18so4406720oiy.9 for ; Thu, 01 Mar 2018 05:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=l/E0mdD3DBfJEUq57ORLTI0/akUTggDmWWruqt17SeE=; b=rH8VJFKierZ1oTdgfZoMGsuFkSu2gClZcZtRuPbanpsaPb8ikvgFWTSd+bnZt5+oQt ChUTDHTCwa/05ShPx14VfncI6VrAEXq1sETLOJkfFqd+yLyrnCsZMKsQI/u/T9YIzto1 2Tx6NvMTwCMMNYqADompcfeojFXVM4PlsSmghXIvklirOIvhdI10vCZ368xGKDUruhR5 dp3/M93EWwDZ2zNIabN7fNDBIy1vSdRuweEJr38WZLedaPioA4Be/31NE8dLahZ7htOx GmMuscavfLg2VFbCjQ8B60X+wGuyaRIon67ErCUfoGbbOIPir/uJyaeLFt2zTzdvHDLw T0AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=l/E0mdD3DBfJEUq57ORLTI0/akUTggDmWWruqt17SeE=; b=RntGfe9bHFUq/IYpieG/MjoPtWEc9B0gEDVrvCuV7Z0TYPirYYYxdNesrwLa0utgzU eF8eupysQNBSt0uLUk6uPIRl1W2ODk0wPqe40/bfseJmXrsuk6f4Xd7p3QpWb6wwe2Ol RkuJ1paxA9lsmKxNrRmA34cmJndKsQru2HWZlgzMF+ux/siloQNGNBdRXdAerH9rAGga 9fJdBki6xwwYNVnmfzfJvgV/z57rWD8Wbe1BpQ4ZH7MZfV/MUKJehwpxvKjfmKTMasAr SD3HgwvhcTQ1ppqAJWREDmk1RM1Q43Uy2grmTK/ctjnIhBi3EcFt79dMCKiT5UVOW8LM FNmg== X-Gm-Message-State: AElRT7EqcGy756JB+/3qaOz5RMy3RcUokA/kOgT2Dr3TAg40Ufu7HZB5 yro/psipWHToU2Dx53qF89WWMNeIowBavqDlXp4= X-Google-Smtp-Source: AG47ELt2y4O3vPBjOoswpHhYSNWVloKa/d1t40CQENv3TTdLIqc+sioYyiBbjR81nqHvWYtKTA0xwPv2MSoYiQ/oxcQ= X-Received: by 10.202.64.131 with SMTP id n125mr1186933oia.26.1519910153744; Thu, 01 Mar 2018 05:15:53 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Thu, 1 Mar 2018 05:15:52 -0800 (PST) In-Reply-To: <1519900936.1252177.1287608280.18488F31@webmail.messagingengine.com> References: <1519900936.1252177.1287608280.18488F31@webmail.messagingengine.com> From: Phillip Hallam-Baker Date: Thu, 1 Mar 2018 08:15:52 -0500 X-Google-Sender-Auth: 4FS_Skw2ckZh1CSEqLQUdRM1rKE Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113de014cdf64b056659a8b3" Archived-At: Subject: Re: [MLS] A different way to do key exchange X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 13:16:03 -0000 --001a113de014cdf64b056659a8b3 Content-Type: text/plain; charset="UTF-8" I see two separate use cases. What I am currently building is a Confidential Document Control system in which documents are encrypted under a single encryption key that corresponds to a group of users. This is equivalent to a security label TOP-SECRET/NOFORN or a project. I can apply those static labels to synchronous communications as well. So if Alice, Bob and Carol are members of the splunge@mathmesh.com recryption group, they can all decrypt the messages provided the key-server performs its part of the key agreement protocol. My protocol is end to end secure and allows people to be added or removed from the group at any time. Compromise of the key server does not permit decryption of any content unless at least one user key is also compromised. The situation we are discussing here is one in which we do not have a pre-arranged group. It is an ad hoc collection of people who come and go. I don't see Round Robin as being impractical in this situation if the number of participants is 20 or less. One of the things I have noticed is that the academic literature on crypto does an awful job of identifying what is a real world requirement and what is not. And it is not just schemes being proposed that are useless because they don't meet a real need. There are a lot of really useful approaches that are dismissed because the academics are insisting on some requirement that is actually irrelevant. It is not just the cryptography that has to scale, the protocol has to scale socially as well. Even IRC has the principle of a channel operator. On Thu, Mar 1, 2018 at 5:42 AM, Katriel Cohn-Gordon wrote: > Hi, > > Thanks for the comment! The two party protocol you describe is pretty > close to MQV, and the three party version is fairly close to > Burmester-Desmedt though with authentication in the exponent. > > The challenge here is that to compute that three-way key in the obvious > manner, you need to do a round robin among all participants: A broadcasts a > value, then B raises it to their private key and rebroadcasts it, then C > and so on. This unfortunately doesn't work if any party is offline. We > tried for a little while to figure out a way to make BD asynchronous, but > without much success. It'd be great if we could though! > > K > > On Wed, 28 Feb 2018, at 10:50 PM, Phillip Hallam-Baker wrote: > > Traditional TLS uses RSA Encryption and RSA signature to perform a key > exchange. Then we do a Diffie Hellman exchange. And if we want client side > authentication, well blerghhh > > > Why not just to a DH exchange? > > let Alice's {private, public} key be {a, A}, Bob's be {b, B} etc. > > A = g^a mod p > B = g^b mod p > etc > > Assume we have a directory that maps Alice->A, Bob->B etc. > > So using straight DH with mutual authentication, the mutually agreed key > is g^ab mod p. We calculate that as A^b mod p or B^a mod p. > > [From this point on, I will drop the mod p] > > This works, but it is not great because now all messages Alice sends to > Bob are encrypted under a single key. Yuk. We also have the problem that > they can be decrypted using Alice's key which she might not want. > > If Alice doesn't need to authenticate herself to Bob, she can just > generate a per-message ephemeral {x, X} and use that instead. The mutual > agreed key is now g^xb. Alice uses a different x each time. And she can > only decrypt the message if she decides to explicitly create a decryption > blob for herself. > > We could use this last exchange plus a HKDF key derivation for TLS with > the same properties as the original RSA exchange but more simply. It does > not give us PFS though, What if we want to get that with one exchange? > > > To get PFS, we are going to need to introduce some sort of nonce or > blinding factor on Bob's side. So lets generate another keypair {y, Y} and > this time we are going to ADD it to Bob's key so that the key agreement > value is g^x(b+y). > > Alice knows x and calculates B^x . Y^x > Bob knows b, y and calculates either X^(b+y) or X^b . X^y > > At this point we are applying Torben Pedersen's Distributed key generation > scheme. And it has wondrous properties. We can perform all the operations > on b in a HSM and perform the blinding factor calculation at the > application level. We can even split the private key between MULTIPLE HSMs. > > [OK I did elide something here, you can add b+y in modular arithmetic, > yes. But it is modulo the subgroup size not the prime. This is p-1 for DH > and (p-1)/8 for our CFRG curves.] > > > OK so now what if we want to perform client side authentication and > involve Alice's credential {a, A} ? > > Easy, the key agreement value is now g^(a+x)(b+y) > > > So here we have one key agreement function that lets us add in or remove > PFS according to whether or not we require it for a particular set of > messages. We can even turn PFS on in the middle of an existing conversation > or turn it off just by dropping the blinding factor out of the mix (or not). > > Want three way key agreement? g^(a+x)(b+y)(c+z) > > Want it in ECC? yes, it all works in Ed25519 or Ed448. It will also work > in Curve 25519 and Curve 448 if someone can point me to a routine to > perform addition of two Montgomery points in the compressed representation. > > > The HSM compartmentalization could be a way to defeat the Spectre and > Meltdown attacks. I showed some of this in a preview of my RSA talk on this. > > All I need is for the CPU manufacturer to provide us with an isolated core > to perform x25519 and x448 operations. The information from that core can > then be used to apply a blinding factor to crypto operations at the > application level. > > > There is a simple proof that this approach is secure if the underlying DH > scheme is. > > *_______________________________________________* > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > --001a113de014cdf64b056659a8b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I s= ee two separate use cases.

What I am currently building is a Confidential Document Control system in= which documents are encrypted under a single encryption key that correspon= ds to a group of users. This is equivalent to a security label TOP-SECRET/N= OFORN or a project.

I can= apply those static labels to synchronous communications as well. So if Ali= ce, Bob and Carol are members of the splunge@mathmesh.com recryption group, they can all decrypt the messa= ges provided the key-server performs its part of the key agreement protocol= .

My protocol is end to e= nd secure and allows people to be added or removed from the group at any ti= me. Compromise of the key server does not permit decryption of any content = unless at least one user key is also compromised.=C2=A0


The situation we are discussing here is one in which w= e do not have a pre-arranged group. It is an ad hoc collection of people wh= o come and go. I don't see Round Robin as being impractical in this sit= uation if the number of participants is 20 or less.

One of the things I have noticed is that the aca= demic literature on crypto does an awful job of identifying what is a real = world requirement and what is not. And it is not just schemes being propose= d that are useless because they don't meet a real need. There are a lot= of really useful approaches that are dismissed because the academics are i= nsisting on some requirement that is actually irrelevant.


It is not just the cryptography that has to scale,= the protocol has to scale socially as well. Even IRC has the principle of = a channel operator.=C2=A0


On Thu, Mar 1, 2018 at 5:42 AM, Katriel Cohn-Gordon &= lt;me@katriel.co.uk> wrote:
Hi,

Thanks for the comment! The two pa= rty protocol you describe is pretty close to MQV, and the three party versi= on is fairly close to Burmester-Desmedt though with authentication in the e= xponent.

The challenge here is that to comp= ute that three-way key in the obvious manner, you need to do a round robin = among all participants: A broadcasts a value, then B raises it to their pri= vate key and rebroadcasts it, then C and so on. This unfortunately doesn= 9;t work if any party is offline. We tried for a little while to figure out= a way to make BD asynchronous, but without much success. It'd be great= if we could though!

K

On Wed, 28 Feb 2018, at 10:50 PM, Phillip Hallam-Baker wrote:
Traditional TLS uses RSA Encryption and R= SA signature to perform a key exchange. Then we do a Diffie Hellman exchang= e. And if we want client side authentication, well blerghhh


Why not just to a DH exchange?

let Alice's {private, public} key be {a,= A}, Bob's be {b, B} etc.

A =3D g^a mod p
B =3D g^b mod p<= /span>
etc

Assume we have a directory that maps Alice-&= gt;A, Bob->B etc.

So using straight DH with mutual authenticat= ion, the mutually agreed key is g^ab mod p. We calculate that as A^b mod p = or B^a mod p.

[From this point on, I will drop the mod p]<= br>

This works, but it is not great because now = all messages Alice sends to Bob are encrypted under a single key. Yuk. We a= lso have the problem that they can be decrypted using Alice's key which= she might not want.

If Alice doesn't need to authenticate he= rself to Bob, she can just generate a per-message ephemeral {x, X} and use = that instead. The mutual agreed key is now g^xb. Alice uses a different x e= ach time. And she can only decrypt the message if she decides to explicitly= create a decryption blob for herself.

We could use this last exchange plus a HKDF = key derivation for TLS with the same properties as the original RSA exchang= e but more simply. It does not give us PFS though, What if we want to get t= hat with one exchange?


To get PFS, we are going to need to introduc= e some sort of nonce or blinding factor on Bob's side. So lets generate= another keypair {y, Y} and this time we are going to ADD it to Bob's k= ey so that the key agreement value is g^x(b+y).

Alice knows x and calculates B^x . Y^x
Bob knows b, y and calculates either X^(b+y)= or X^b . X^y

At this point we are applying Torben Pederse= n's Distributed key generation scheme. And it has wondrous properties. = We can perform all the operations on b in a HSM and perform the blinding fa= ctor calculation at the application level. We can even split the private ke= y between MULTIPLE HSMs.

[OK I did elide something here, you can add = b+y in modular arithmetic, yes. But it is modulo the subgroup size not the = prime. This is p-1 for DH and (p-1)/8 for our CFRG curves.]


OK so now what if we want to perform client = side authentication and involve Alice's credential {a, A} ?

Easy, the key agreement value is now g^(a+x)= (b+y)


So here we have one key agreement function t= hat lets us add in or remove PFS according to whether or not we require it = for a particular set of messages. We can even turn PFS on in the middle of = an existing conversation or turn it off just by dropping the blinding facto= r out of the mix (or not).

Want three way key agreement?=C2=A0 g^(a+x)(b+y)(c+z)
Want it in ECC? yes, it all wo= rks in Ed25519 or Ed448. It will also work in Curve 25519 and Curve 448 if = someone can point me to a routine to perform addition of two Montgomery poi= nts in the compressed representation.
The HSM compartmentalization could be a way = to defeat the Spectre and Meltdown attacks. I showed some of this in a prev= iew of my RSA talk on this.

All I need is for the CPU manufacturer to pr= ovide us with an isolated core to perform x25519 and x448 operations. The i= nformation from that core can then be used to apply a blinding factor to cr= ypto operations at the application level.=C2=A0


There is a simple proof that this approach i= s secure if the underlying DH scheme is.=C2=A0

_________________________________= ______________
MLS mailing list


--001a113de014cdf64b056659a8b3-- From nobody Thu Mar 1 07:11:28 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6623212D77E for ; Thu, 1 Mar 2018 07:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og_zBNDrH2WJ for ; Thu, 1 Mar 2018 07:11:25 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEA7126DED for ; Thu, 1 Mar 2018 07:11:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 905D830066F for ; Thu, 1 Mar 2018 10:11:23 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id F-2tXpQZhn80 for ; Thu, 1 Mar 2018 10:11:22 -0500 (EST) Received: from [172.22.112.5] (unknown [65.132.39.155]) by mail.smeinc.net (Postfix) with ESMTPSA id A8747300590 for ; Thu, 1 Mar 2018 10:11:22 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_3954E772-B48D-40AF-8931-D655B4BA06A9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 1 Mar 2018 10:11:23 -0500 References: To: mls@ietf.org In-Reply-To: Message-Id: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 15:11:26 -0000 --Apple-Mail=_3954E772-B48D-40AF-8931-D655B4BA06A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Generally, I think the right answer to these, however, isn't to modify = the messaging protocol but rather to add that functionality on the = messaging app over the top. That also is a much easier way to do new = device history sync This is similar to the approach used in some email environments. The = email message is decrypted for reading, and then encrypted in a separate = archive key for storage. Russ --Apple-Mail=_3954E772-B48D-40AF-8931-D655B4BA06A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Generally, I think the right = answer to these, however, isn't to modify the messaging protocol but = rather to add that functionality on the messaging app over the top. That = also is a much easier way to do new device history = sync

This = is similar to the approach used in some email environments.  The = email message is decrypted for reading, and then encrypted in a separate = archive key for storage.

Russ

= --Apple-Mail=_3954E772-B48D-40AF-8931-D655B4BA06A9-- From nobody Thu Mar 1 08:34:35 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E55712EB1F for ; Thu, 1 Mar 2018 08:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cncGN8cr0dxu for ; Thu, 1 Mar 2018 08:34:32 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866EB12EB08 for ; Thu, 1 Mar 2018 08:34:32 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id t185so4907633oif.6 for ; Thu, 01 Mar 2018 08:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dIpz3B7sOd3J1W+n9W5yzZ4wlN1xpQtgssgCcVIkD0U=; b=W/HO8v/9ssya+MfmUH1dkIUSklKu0+s2pZBW5/ktSZ9bU3vgPzulI//pnRRZpdGWIo WLViAHhjRCjvfbhK3fHbDMc7sczX8RYD1gFqnpIpMoDVEMMSPnmA23JkiPNH3Xl0y7QC YHDCe1gDzSAiO7gsY0yvO01ZOaPrKPaxAz6+iohjJ8Wm3sw/ibVmeXt/xH6XZ7UPyxEv 0W+d6ehNxJhdRbDMBoq1tLfv82ncpMDSM8z85H/GwmegyUwUivX9gIF1UWXRCVduvEaC J8enN8r6U3wON8OcYVrq/1Mbx6tJ9uVe5NOiHdi/TM7Jaro8Ob1X42iEmPBlvTf9hBNb ewCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dIpz3B7sOd3J1W+n9W5yzZ4wlN1xpQtgssgCcVIkD0U=; b=CJhDN8+MiED5+MpOr+JEOYxy11QjhSyOVJgHT9x1gs8w48EpvbLh7Qamf6dKETFLBZ ljsiCB7zf4ducxbIIcRuvIKhk28JU6e4jpAyTi2vY4maDg8PFQNQODYVk71W9ry9IwSt GjGd4uLGB/XD4fzQOqCuFRZyXPdj0BjIUZmz1cDpnnCjAZ/BL49ARU/srISLW3VGNjNM iL6jTdxC9h8+0YR8EbMVjvuds0MIHFGQgJQwFT9Ka3BnigIM5Gy2zQr2wuxt/RnA3kIp F6ESMR3i+iBSpSdnZ+pGe1x412pGKhmu6ZheT8YEhbZALteC7fMMOnsfLgONwmVtGZNi VG8Q== X-Gm-Message-State: APf1xPCFrtFdujwSU9QGfK6aVbEMhRc+tu0cbiMcAYVNqKTZsWlr8fip oj3/yRX36faf/0f8DmwYFyWLPNSoBoHnm9v7EdM= X-Google-Smtp-Source: AG47ELsir8SGcvKrpqVQDpREpCJ7AOe9Irncsq2Nh133Xl075aouTUUQ/+xgSembwwgIOeX9yj/ZIrO3+UORCs4rXho= X-Received: by 10.202.206.71 with SMTP id e68mr1690766oig.34.1519922071685; Thu, 01 Mar 2018 08:34:31 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Thu, 1 Mar 2018 08:34:31 -0800 (PST) In-Reply-To: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> From: Phillip Hallam-Baker Date: Thu, 1 Mar 2018 11:34:31 -0500 X-Google-Sender-Auth: 4K8azi3mps1Xtu0X7RzQ284aWM8 Message-ID: To: Russ Housley Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113cdb042b4ec205665c6f22" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 16:34:34 -0000 --001a113cdb042b4ec205665c6f22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley wrote: > > Generally, I think the right answer to these, however, isn't to modify th= e > messaging protocol but rather to add that functionality on the messaging > app over the top. That also is a much easier way to do new device history > sync > > > This is similar to the approach used in some email environments. The > email message is decrypted for reading, and then encrypted in a separate > archive key for storage. > > Russ > =E2=80=8BIt is a valid approach and it might be the right approach. =E2=80=8B =E2=80=8BBut what we have right now is a rather complex proposal that may o= r may not be correct and may or may not be addressing the real requirements and may or may not be addressing them in the most straightforward fashion. So far I have seen a lot of defensive responses and one individual whose behavior was bullying. Now the fact that I cannot be bullied out of my opinions does not make =E2=80=8Bthe experience of people making personal at= tacks any more pleasant for me. More importantly, I am concerned that what has been more or less explicitly stated is 'we have our proposal and if you don't like it then bog off'. I don't think that language encourages honest debate about the limitations of the proposal or identifying the flaws. I would much rather the IETF endorse no proposal than one that only navigates the process because a group of bullies shouted down anyone who was critical of it. We saw that happen with DANE we saw it happen with CBOR. CBOR does work but the consequence of shutting down the voices saying that we needed a binary format that precisely matches the semantics of JSON is that we had to spin up a separate COSE working group to repeat the work of JOSE rather than simply apply the encoding. The assumption of most here is that the requirements are easy and the cryptography is hard. That is precisely the wrong way round. If we really understand what the requirements are, the cryptography follows almost directly. It is getting to the understanding of the requirements that is the hard part. --001a113cdb042b4ec205665c6f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, Mar 1, 2018 at 10:11 AM, Russ Housley <housley@vigilsec.com>= ; wrote:

Generally, I think the= right answer to these, however, isn't to modify the messaging protocol= but rather to add that functionality on the messaging app over the top. Th= at also is a much easier way to do new device history sync

This is similar to the approach used in some = email environments.=C2=A0 The email message is decrypted for reading, and t= hen encrypted in a separate archive key for storage.

Russ
<= /div>

=E2=80=8BIt is a valid approach and it might be the right= approach.
=E2= =80=8B
=E2=80=8BBut what we have right now is a rather complex proposal that ma= y or may not be correct and may or may not be addressing the real requireme= nts and may or may not be addressing them in the most straightforward fashi= on.

<= div class=3D"gmail_default" style=3D"font-size:small">So far I have seen a = lot of defensive responses and one individual whose behavior was bullying. = Now the fact that I cannot be bullied out of my opinions does not make =E2= =80=8Bthe experience of people making personal attacks any more pleasant fo= r me.=C2=A0
More importan= tly, I am concerned that what has been more or less explicitly stated is &#= 39;we have our proposal and if you don't like it then bog off'.

I don't think that langu= age encourages honest debate about the limitations of the proposal or ident= ifying the flaws.=C2=A0

I= would much rather the IETF endorse no proposal than one that only navigate= s the process because a group of bullies shouted down anyone who was critic= al of it. We saw that happen with DANE we saw it happen with CBOR. CBOR doe= s work but the consequence of shutting down the voices saying that we neede= d a binary format that precisely matches the semantics of JSON is that we h= ad to spin up a separate COSE working group to repeat the work of JOSE rath= er than simply apply the encoding.


The assumption of most here is that the requirements are easy and the cryp= tography is hard. That is precisely the wrong way round. If we really under= stand what the requirements are, the cryptography follows almost directly. = It is getting to the understanding of the requirements that is the hard par= t.





--001a113cdb042b4ec205665c6f22-- From nobody Thu Mar 1 09:00:22 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9CE12EB70 for ; Thu, 1 Mar 2018 09:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Zmy2vrit; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=CIn5vjRe 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 9p7uarqwZ4pv for ; Thu, 1 Mar 2018 09:00:18 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEA212EB68 for ; Thu, 1 Mar 2018 09:00:03 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w21GsOrb025233; Thu, 1 Mar 2018 09:00:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=7d6WaH31GmlhK/AjVSDYwN2h4SRz86b/vAQmV6+nAbQ=; b=Zmy2vritahS/K+KkGg1B+2PXNEHlIXKAErVTb935BJkGoADOhybXX5WKWqbL6FY1cotZ E3kGZEsITsI/33ueg+mDLnCQ+YKvLlDchJ820SyRSwf9tw3Z7sgWo3QgzA3zYGjFXyWN /0lKIs5xw8LPKafqgDx4xGMGLpSW1F65br8= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2gecqb98jy-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Mar 2018 09:00:00 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Mar 2018 11:59:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7d6WaH31GmlhK/AjVSDYwN2h4SRz86b/vAQmV6+nAbQ=; b=CIn5vjReicguqBdx+X+ouhw/7I7+K+lW1vydQFbybUgAFwQfM4mLCl8vSG5B9tv1nohyP3BY2PxhKKoa98y0v0rPPnIx1HNrNRnrUnxc4krZgiD1h64u1BL11wJ41hcGlX1IQtjnUIKDWBTbyVdogmRuRGItUlUeQuHtkqpQ2Qk= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1735.namprd15.prod.outlook.com (10.174.53.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Thu, 1 Mar 2018 16:59:58 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::3028:3f8c:6eeb:3256]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::3028:3f8c:6eeb:3256%17]) with mapi id 15.20.0527.021; Thu, 1 Mar 2018 16:59:58 +0000 From: Jon Millican To: Phillip Hallam-Baker , Russ Housley CC: "mls@ietf.org" Thread-Topic: [MLS] Use Cases for avoiding Forward Secrecy Thread-Index: AQHTsLeowtsdDTBzZk+HHlXOjx9LuqO6c26AgAEKQYCAABc6gIAABxoA Date: Thu, 1 Mar 2018 16:59:57 +0000 Message-ID: <6337AD1B-D1A8-4D3F-8890-A36ED46B47D9@fb.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:180::1:8f46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1735; 7:sukX+/RfrqsPg4Zud+3Ds3ShGcSHE3QNfYTjqqT9UMX0TU+6TxWlxmSXhGlgTtGUELJ7NMZJyJIw/OxpqSuFCRNLhUWgwSP4P78KvGyo+ZXY2VbaEibFf5V2A+DzrB/F7LnV4D33z1PAd0vdNBzSgDZJnPWUhcgjCdBuNu77fnq2gGavSfscVnlByEwrbqFSFdz/0wJzwJeHTDPbVlXKult5zXaXL7A/3303RQKQNs+qJd3gwf1q6dL0LlbxXHd4; 20:Zzk5dHOp1WqLJiEaCHbkio/lM6WWEdNRALWflGjkVKLaESI6Fw7CDdQDgOR1Se4KX6NczwKukRRqZkAyj/FkDsRwRuRidNbxauWZ5RiE29Tep7wkKuKKVDdCvjnpMDPWM6xa5DBaC6B2mve0Qro62hmlWiYqao2jMQOAfK9EQdU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f3acf6b1-6043-4e0a-ae86-08d57f95dd2b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR15MB1735; x-ms-traffictypediagnostic: CY4PR15MB1735: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(11241501184)(944501224)(93006095)(93001095)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR15MB1735; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1735; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(346002)(396003)(376002)(199004)(189003)(102836004)(97736004)(82746002)(110136005)(99286004)(561944003)(93886005)(236005)(6486002)(25786009)(4326008)(6512007)(54896002)(6306002)(316002)(186003)(3280700002)(6116002)(6506007)(53546011)(5250100002)(2906002)(105586002)(14454004)(478600001)(76176011)(59450400001)(2900100001)(68736007)(8936002)(5660300001)(83716003)(7736002)(53936002)(81156014)(6246003)(8676002)(3660700001)(81166006)(33656002)(229853002)(2950100002)(6436002)(86362001)(36756003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1735; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fVdfJTrt2ZczHrbpIHc75es2slgLH9GycOhnQJtWJY61d6+mz6venmL7L3DthI6B6fA0KyU+bC6VtKSZOYkduQY0WrY2BmbV8/u5ZQjZj3rHzvAaH/5Ar2B5lgS5WbcCres/VUb8WKHH3nSL3dhTmywy9x1R59WexthZUjv6L4w= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6337AD1BD1A84D3F8890A36ED46B47D9fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f3acf6b1-6043-4e0a-ae86-08d57f95dd2b X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 16:59:57.8712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1735 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-01_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:00:21 -0000 --_000_6337AD1BD1A84D3F8890A36ED46B47D9fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgdGhlIHF1ZXN0aW9uIGlzIGFib3V0IHdoZXRoZXIgTUxTIHNob3VsZCBzdXBwb3J0IGZvcndh cmQgc2VjcmVjeSBpbiB0aGUgZmlyc3QgcGxhY2UsIEkgdGhpbmsgY29uc3VtZXIgRTJFIG1lc3Nh Z2luZyBhcHBsaWNhdGlvbnMgcHJvdmlkZSBhIGdvb2QgdXNlIGNhc2UgZm9yIHRoaXMuIFRoZSB0 aHJlYXQgbW9kZWwgdGhhdCB3ZSB0ZW5kIHRvIHRha2UgaGVyZSBpcyB0aGF0IHRoZSB1c2VyIGhh cyBsaW1pdGVkIHRydXN0IGluIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLiBJbiB0aGlzIHNpdHVhdGlv biwgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgcHJvdmlkZWQgYnkgVExTIGFyZSBhbG1vc3QgbW9v dCwgYXMgVExTIG9ubHkgcHJvdGVjdHMgeW91IGFzIGZhciBhcyB0aGUgc2VydmljZSBwcm92aWRl ciBhbnl3YXkuDQoNCkVwaGVtZXJhbGl0eSBpcyBhIHZlcnkgY29tbW9uIHByb3BlcnR5IGluIHN1 Y2ggYXBwcywgd2l0aCB0aGUgZXhwbGljaXQgZ29hbCB0aGF0IG1lc3NhZ2VzIG5vdCBiZSBhY2Nl c3NpYmxlIGFmdGVyIGEgY2VydGFpbiBwZXJpb2QuIEV2ZW4gd2l0aG91dCBlcGhlbWVyYWxpdHks IEkgYmVsaWV2ZSB0aGF0IG1vc3QgbWVzc2FnaW5nIHN1cHBvcnQgbWVzc2FnZSBkZWxldGlvbi4g SW4gc3VjaCBzaXR1YXRpb25zLCBmb3J3YXJkIHNlY3JlY3kgaXMgdmVyeSBkZXNpcmFibGUsIGFz IGl0IGVuc3VyZXMgdGhhdCBpZiBrZXlzIG9yIGFueSBkZXZpY2Ugc3RhdGUgZG8gbGVhayBhdCBh bnkgbW9tZW50IChiZSBpdCBmcm9tIGFuIGV4cGxvaXQsIHNvbWVib2R5IGltYWdpbmcgYSBkZXZp Y2UsIG9yIGEgdGVtcG9yYXJ5IGJ1ZyBpbiB0aGUgYXBwIGl0c2VsZiksIHVzZXJz4oCZIG9sZCBt ZXNzYWdlcyBjYW4gYXQgbGVhc3QgcmVtYWluIHNlY3JldCwgZXZlbiBpZiB0aGUgcHJvdmlkZXIg aGFkIHJldGFpbmVkIGFsbCBvZiB0aGVpciBjaXBoZXJ0ZXh0cy4gVGhpcyBhbHNvIGxlYWRzIHRv IGEgc2ltaWxhciBjYXNlIGZvciBQb3N0LUNvbXByb21pc2UgU2VjdXJpdHksIGluIHRoYXQgc2Vj cmVjeSBjYW4gYmUgcmVjb3ZlcmVkIGV2ZW4gYWZ0ZXIgYW55IHNvcnQgb2Yga2V5IGxlYWthZ2U6 IGFsdGhvdWdoIGluIHRoaXMgY2FzZSB0aGUgYXJndW1lbnQgYXBwbGllcyBldmVuIHdoZW4gbm8g bWVzc2FnZXMgYXJlIGV2ZXIgZGVsZXRlZC4NCg0KT24gMDEvMDMvMjAxOCwgMTY6MzUsICJNTFMg b24gYmVoYWxmIG9mIFBoaWxsaXAgSGFsbGFtLUJha2VyIiA8bWxzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOm1scy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgcGhpbGxAaGFsbGFtYmFr ZXIuY29tPG1haWx0bzpwaGlsbEBoYWxsYW1iYWtlci5jb20+PiB3cm90ZToNCg0KT24gVGh1LCBN YXIgMSwgMjAxOCBhdCAxMDoxMSBBTSwgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNv bTxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+PiB3cm90ZToNCg0KR2VuZXJhbGx5LCBJIHRo aW5rIHRoZSByaWdodCBhbnN3ZXIgdG8gdGhlc2UsIGhvd2V2ZXIsIGlzbid0IHRvIG1vZGlmeSB0 aGUgbWVzc2FnaW5nIHByb3RvY29sIGJ1dCByYXRoZXIgdG8gYWRkIHRoYXQgZnVuY3Rpb25hbGl0 eSBvbiB0aGUgbWVzc2FnaW5nIGFwcCBvdmVyIHRoZSB0b3AuIFRoYXQgYWxzbyBpcyBhIG11Y2gg ZWFzaWVyIHdheSB0byBkbyBuZXcgZGV2aWNlIGhpc3Rvcnkgc3luYw0KDQpUaGlzIGlzIHNpbWls YXIgdG8gdGhlIGFwcHJvYWNoIHVzZWQgaW4gc29tZSBlbWFpbCBlbnZpcm9ubWVudHMuICBUaGUg ZW1haWwgbWVzc2FnZSBpcyBkZWNyeXB0ZWQgZm9yIHJlYWRpbmcsIGFuZCB0aGVuIGVuY3J5cHRl ZCBpbiBhIHNlcGFyYXRlIGFyY2hpdmUga2V5IGZvciBzdG9yYWdlLg0KDQpSdXNzDQoNCuKAi0l0 IGlzIGEgdmFsaWQgYXBwcm9hY2ggYW5kIGl0IG1pZ2h0IGJlIHRoZSByaWdodCBhcHByb2FjaC4N CuKAiw0K4oCLQnV0IHdoYXQgd2UgaGF2ZSByaWdodCBub3cgaXMgYSByYXRoZXIgY29tcGxleCBw cm9wb3NhbCB0aGF0IG1heSBvciBtYXkgbm90IGJlIGNvcnJlY3QgYW5kIG1heSBvciBtYXkgbm90 IGJlIGFkZHJlc3NpbmcgdGhlIHJlYWwgcmVxdWlyZW1lbnRzIGFuZCBtYXkgb3IgbWF5IG5vdCBi ZSBhZGRyZXNzaW5nIHRoZW0gaW4gdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGZhc2hpb24uDQoN ClNvIGZhciBJIGhhdmUgc2VlbiBhIGxvdCBvZiBkZWZlbnNpdmUgcmVzcG9uc2VzIGFuZCBvbmUg aW5kaXZpZHVhbCB3aG9zZSBiZWhhdmlvciB3YXMgYnVsbHlpbmcuIE5vdyB0aGUgZmFjdCB0aGF0 IEkgY2Fubm90IGJlIGJ1bGxpZWQgb3V0IG9mIG15IG9waW5pb25zIGRvZXMgbm90IG1ha2Ug4oCL dGhlIGV4cGVyaWVuY2Ugb2YgcGVvcGxlIG1ha2luZyBwZXJzb25hbCBhdHRhY2tzIGFueSBtb3Jl IHBsZWFzYW50IGZvciBtZS4NCg0KTW9yZSBpbXBvcnRhbnRseSwgSSBhbSBjb25jZXJuZWQgdGhh dCB3aGF0IGhhcyBiZWVuIG1vcmUgb3IgbGVzcyBleHBsaWNpdGx5IHN0YXRlZCBpcyAnd2UgaGF2 ZSBvdXIgcHJvcG9zYWwgYW5kIGlmIHlvdSBkb24ndCBsaWtlIGl0IHRoZW4gYm9nIG9mZicuDQoN CkkgZG9uJ3QgdGhpbmsgdGhhdCBsYW5ndWFnZSBlbmNvdXJhZ2VzIGhvbmVzdCBkZWJhdGUgYWJv dXQgdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBwcm9wb3NhbCBvciBpZGVudGlmeWluZyB0aGUgZmxh d3MuDQoNCkkgd291bGQgbXVjaCByYXRoZXIgdGhlIElFVEYgZW5kb3JzZSBubyBwcm9wb3NhbCB0 aGFuIG9uZSB0aGF0IG9ubHkgbmF2aWdhdGVzIHRoZSBwcm9jZXNzIGJlY2F1c2UgYSBncm91cCBv ZiBidWxsaWVzIHNob3V0ZWQgZG93biBhbnlvbmUgd2hvIHdhcyBjcml0aWNhbCBvZiBpdC4gV2Ug c2F3IHRoYXQgaGFwcGVuIHdpdGggREFORSB3ZSBzYXcgaXQgaGFwcGVuIHdpdGggQ0JPUi4gQ0JP UiBkb2VzIHdvcmsgYnV0IHRoZSBjb25zZXF1ZW5jZSBvZiBzaHV0dGluZyBkb3duIHRoZSB2b2lj ZXMgc2F5aW5nIHRoYXQgd2UgbmVlZGVkIGEgYmluYXJ5IGZvcm1hdCB0aGF0IHByZWNpc2VseSBt YXRjaGVzIHRoZSBzZW1hbnRpY3Mgb2YgSlNPTiBpcyB0aGF0IHdlIGhhZCB0byBzcGluIHVwIGEg c2VwYXJhdGUgQ09TRSB3b3JraW5nIGdyb3VwIHRvIHJlcGVhdCB0aGUgd29yayBvZiBKT1NFIHJh dGhlciB0aGFuIHNpbXBseSBhcHBseSB0aGUgZW5jb2RpbmcuDQoNCg0KVGhlIGFzc3VtcHRpb24g b2YgbW9zdCBoZXJlIGlzIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBhcmUgZWFzeSBhbmQgdGhlIGNy eXB0b2dyYXBoeSBpcyBoYXJkLiBUaGF0IGlzIHByZWNpc2VseSB0aGUgd3Jvbmcgd2F5IHJvdW5k LiBJZiB3ZSByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IHRoZSByZXF1aXJlbWVudHMgYXJlLCB0aGUg Y3J5cHRvZ3JhcGh5IGZvbGxvd3MgYWxtb3N0IGRpcmVjdGx5LiBJdCBpcyBnZXR0aW5nIHRvIHRo ZSB1bmRlcnN0YW5kaW5nIG9mIHRoZSByZXF1aXJlbWVudHMgdGhhdCBpcyB0aGUgaGFyZCBwYXJ0 Lg0KDQoNCg0KDQoNCg== --_000_6337AD1BD1A84D3F8890A36ED46B47D9fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <89D0238215D87E4B9B88D1A0842AB38B@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklm IHRoZSBxdWVzdGlvbiBpcyBhYm91dCB3aGV0aGVyIE1MUyBzaG91bGQgc3VwcG9ydCBmb3J3YXJk IHNlY3JlY3kgaW4gdGhlIGZpcnN0IHBsYWNlLCBJIHRoaW5rIGNvbnN1bWVyIEUyRSBtZXNzYWdp bmcgYXBwbGljYXRpb25zIHByb3ZpZGUgYSBnb29kIHVzZSBjYXNlIGZvciB0aGlzLiBUaGUgdGhy ZWF0IG1vZGVsIHRoYXQgd2UgdGVuZA0KIHRvIHRha2UgaGVyZSBpcyB0aGF0IHRoZSB1c2VyIGhh cyBsaW1pdGVkIHRydXN0IGluIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLiBJbiB0aGlzIHNpdHVhdGlv biwgdGhlIHNlY3VyaXR5IHByb3BlcnRpZXMgcHJvdmlkZWQgYnkgVExTIGFyZSBhbG1vc3QgbW9v dCwgYXMgVExTIG9ubHkgcHJvdGVjdHMgeW91IGFzIGZhciBhcyB0aGUgc2VydmljZSBwcm92aWRl ciBhbnl3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkVwaGVtZXJhbGl0eSBpcyBhIHZlcnkgY29tbW9uIHByb3BlcnR5IGlu IHN1Y2ggYXBwcywgd2l0aCB0aGUgZXhwbGljaXQgZ29hbCB0aGF0IG1lc3NhZ2VzIG5vdCBiZSBh Y2Nlc3NpYmxlIGFmdGVyIGEgY2VydGFpbiBwZXJpb2QuIEV2ZW4gd2l0aG91dCBlcGhlbWVyYWxp dHksIEkgYmVsaWV2ZSB0aGF0IG1vc3QgbWVzc2FnaW5nIHN1cHBvcnQNCiBtZXNzYWdlIGRlbGV0 aW9uLiBJbiBzdWNoIHNpdHVhdGlvbnMsIGZvcndhcmQgc2VjcmVjeSBpcyB2ZXJ5IGRlc2lyYWJs ZSwgYXMgaXQgZW5zdXJlcyB0aGF0IGlmIGtleXMgb3IgYW55IGRldmljZSBzdGF0ZSBkbyBsZWFr IGF0IGFueSBtb21lbnQgKGJlIGl0IGZyb20gYW4gZXhwbG9pdCwgc29tZWJvZHkgaW1hZ2luZyBh IGRldmljZSwgb3IgYSB0ZW1wb3JhcnkgYnVnIGluIHRoZSBhcHAgaXRzZWxmKSwgdXNlcnPigJkg b2xkIG1lc3NhZ2VzIGNhbg0KIGF0IGxlYXN0IHJlbWFpbiBzZWNyZXQsIGV2ZW4gaWYgdGhlIHBy b3ZpZGVyIGhhZCByZXRhaW5lZCBhbGwgb2YgdGhlaXIgY2lwaGVydGV4dHMuIFRoaXMgYWxzbyBs ZWFkcyB0byBhIHNpbWlsYXIgY2FzZSBmb3IgUG9zdC1Db21wcm9taXNlIFNlY3VyaXR5LCBpbiB0 aGF0IHNlY3JlY3kgY2FuIGJlIHJlY292ZXJlZCBldmVuIGFmdGVyIGFueSBzb3J0IG9mIGtleSBs ZWFrYWdlOiBhbHRob3VnaCBpbiB0aGlzIGNhc2UgdGhlIGFyZ3VtZW50IGFwcGxpZXMNCiBldmVu IHdoZW4gbm8gbWVzc2FnZXMgYXJlIGV2ZXIgZGVsZXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMDEvMDMvMjAxOCwg MTY6MzUsICZxdW90O01MUyBvbiBiZWhhbGYgb2YgUGhpbGxpcCBIYWxsYW0tQmFrZXImcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZyI+bWxzLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnBoaWxsQGhhbGxhbWJha2Vy LmNvbSI+cGhpbGxAaGFsbGFtYmFrZXIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIG5h bWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24g VGh1LCBNYXIgMSwgMjAxOCBhdCAxMDoxMSBBTSwgUnVzcyBIb3VzbGV5ICZsdDs8L3NwYW4+PC9h PjxhIGhyZWY9Im1haWx0bzpob3VzbGV5QHZpZ2lsc2VjLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5ob3VzbGV5QHZpZ2lsc2VjLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5HZW5lcmFsbHks IEkgdGhpbmsgdGhlIHJpZ2h0IGFuc3dlciB0byB0aGVzZSwgaG93ZXZlciwgaXNuJ3QgdG8gbW9k aWZ5IHRoZSBtZXNzYWdpbmcgcHJvdG9jb2wgYnV0IHJhdGhlciB0byBhZGQNCiB0aGF0IGZ1bmN0 aW9uYWxpdHkgb24gdGhlIG1lc3NhZ2luZyBhcHAgb3ZlciB0aGUgdG9wLiBUaGF0IGFsc28gaXMg YSBtdWNoIGVhc2llciB3YXkgdG8gZG8gbmV3IGRldmljZSBoaXN0b3J5IHN5bmM8bzpwPjwvbzpw Pjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRo aXMgaXMgc2ltaWxhciB0byB0aGUgYXBwcm9hY2ggdXNlZCBpbiBzb21lIGVtYWlsIGVudmlyb25t ZW50cy4mbmJzcDsgVGhlIGVtYWlsIG1lc3NhZ2UgaXMgZGVjcnlwdGVkIGZvciByZWFkaW5nLCBh bmQgdGhlbiBlbmNyeXB0ZWQgaW4gYSBzZXBhcmF0ZSBhcmNoaXZlIGtleSBmb3Igc3RvcmFnZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5SdXNzPG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igItJdCBpcyBh IHZhbGlkIGFwcHJvYWNoIGFuZCBpdCBtaWdodCBiZSB0aGUgcmlnaHQgYXBwcm9hY2guPG86cD48 L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij7igIs8bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPuKAi0J1dCB3aGF0IHdlIGhhdmUgcmlnaHQgbm93IGlzIGEgcmF0aGVyIGNvbXBs ZXggcHJvcG9zYWwgdGhhdCBtYXkgb3IgbWF5IG5vdCBiZSBjb3JyZWN0IGFuZCBtYXkgb3IgbWF5 IG5vdCBiZSBhZGRyZXNzaW5nIHRoZSByZWFsIHJlcXVpcmVtZW50cw0KIGFuZCBtYXkgb3IgbWF5 IG5vdCBiZSBhZGRyZXNzaW5nIHRoZW0gaW4gdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGZhc2hp b24uPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPlNvIGZhciBJIGhhdmUgc2VlbiBhIGxvdCBvZiBkZWZlbnNpdmUgcmVzcG9uc2VzIGFu ZCBvbmUgaW5kaXZpZHVhbCB3aG9zZSBiZWhhdmlvciB3YXMgYnVsbHlpbmcuIE5vdyB0aGUgZmFj dCB0aGF0IEkgY2Fubm90IGJlIGJ1bGxpZWQNCiBvdXQgb2YgbXkgb3BpbmlvbnMgZG9lcyBub3Qg bWFrZSDigIt0aGUgZXhwZXJpZW5jZSBvZiBwZW9wbGUgbWFraW5nIHBlcnNvbmFsIGF0dGFja3Mg YW55IG1vcmUgcGxlYXNhbnQgZm9yIG1lLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Nb3JlIGltcG9ydGFudGx5LCBJIGFt IGNvbmNlcm5lZCB0aGF0IHdoYXQgaGFzIGJlZW4gbW9yZSBvciBsZXNzIGV4cGxpY2l0bHkgc3Rh dGVkIGlzICd3ZSBoYXZlIG91ciBwcm9wb3NhbCBhbmQgaWYgeW91IGRvbid0IGxpa2UgaXQNCiB0 aGVuIGJvZyBvZmYnLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5JIGRvbid0IHRoaW5rIHRoYXQgbGFuZ3VhZ2UgZW5jb3VyYWdlcyBo b25lc3QgZGViYXRlIGFib3V0IHRoZSBsaW1pdGF0aW9ucyBvZiB0aGUgcHJvcG9zYWwgb3IgaWRl bnRpZnlpbmcgdGhlIGZsYXdzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIHdvdWxkIG11Y2ggcmF0aGVyIHRoZSBJRVRG IGVuZG9yc2Ugbm8gcHJvcG9zYWwgdGhhbiBvbmUgdGhhdCBvbmx5IG5hdmlnYXRlcyB0aGUgcHJv Y2VzcyBiZWNhdXNlIGEgZ3JvdXAgb2YgYnVsbGllcyBzaG91dGVkIGRvd24gYW55b25lDQogd2hv IHdhcyBjcml0aWNhbCBvZiBpdC4gV2Ugc2F3IHRoYXQgaGFwcGVuIHdpdGggREFORSB3ZSBzYXcg aXQgaGFwcGVuIHdpdGggQ0JPUi4gQ0JPUiBkb2VzIHdvcmsgYnV0IHRoZSBjb25zZXF1ZW5jZSBv ZiBzaHV0dGluZyBkb3duIHRoZSB2b2ljZXMgc2F5aW5nIHRoYXQgd2UgbmVlZGVkIGEgYmluYXJ5 IGZvcm1hdCB0aGF0IHByZWNpc2VseSBtYXRjaGVzIHRoZSBzZW1hbnRpY3Mgb2YgSlNPTiBpcyB0 aGF0IHdlIGhhZCB0byBzcGluIHVwIGEgc2VwYXJhdGUNCiBDT1NFIHdvcmtpbmcgZ3JvdXAgdG8g cmVwZWF0IHRoZSB3b3JrIG9mIEpPU0UgcmF0aGVyIHRoYW4gc2ltcGx5IGFwcGx5IHRoZSBlbmNv ZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5UaGUgYXNzdW1wdGlvbiBvZiBtb3N0IGhlcmUgaXMgdGhhdCB0aGUgcmVx dWlyZW1lbnRzIGFyZSBlYXN5IGFuZCB0aGUgY3J5cHRvZ3JhcGh5IGlzIGhhcmQuIFRoYXQgaXMg cHJlY2lzZWx5IHRoZSB3cm9uZyB3YXkgcm91bmQuIElmDQogd2UgcmVhbGx5IHVuZGVyc3RhbmQg d2hhdCB0aGUgcmVxdWlyZW1lbnRzIGFyZSwgdGhlIGNyeXB0b2dyYXBoeSBmb2xsb3dzIGFsbW9z dCBkaXJlY3RseS4gSXQgaXMgZ2V0dGluZyB0byB0aGUgdW5kZXJzdGFuZGluZyBvZiB0aGUgcmVx dWlyZW1lbnRzIHRoYXQgaXMgdGhlIGhhcmQgcGFydC48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3Nw YW4+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6337AD1BD1A84D3F8890A36ED46B47D9fbcom_-- From nobody Thu Mar 1 09:06:28 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8512EB6B for ; Thu, 1 Mar 2018 09:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC8xrXysXAQ0 for ; Thu, 1 Mar 2018 09:06:23 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7307812EB6C for ; Thu, 1 Mar 2018 09:06:13 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id a23so8450446qtn.0 for ; Thu, 01 Mar 2018 09:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7QI/az2/LxKPj3N+EP0C9brfwHBCWnfqYxioMyMUd4=; b=SyYYTr3PWlv/FBSyxTz2rEA7kS5eeeGQMXe/15Qqy10lXIVjC+mELDjvh78SWmV/1X +fMOVcYqC6Ajk/rBW79kvnSuO8EgPEfFchZ1614WSK3BBkEJZk4AKp62BxfsxSmizlH2 kppG0R9MJWU8z5mzKvff6gJ1Gv++fDBsm4qUg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w7QI/az2/LxKPj3N+EP0C9brfwHBCWnfqYxioMyMUd4=; b=iCnqVAkPA28KO/MIr4p5TCDFWAAZ7ak2Iw7UV51VDmi8VMI6nLf0fGNoSqPD1XQXyP Ft6tZqhD1Bu6EWNm0h+86g5PLLcV78YIZ2sQoqQqGaddL3GNzqrLfdawUq2dnSxCvLVY Ng4HpyCF4HUxCLBgLT2SVVbBvMf369sDF9vRzDpZDDPlowJg2zCPWuW0MQ6LABAnUq2E Tx2Gn6WagDJWksiLygRnjbOs2JhE9Nc6AMDmG6e47+rP+ADB0opwJS/0VoWwzOZZTdrW VlVLh66T5JI1Uojf62TOZnC06Ovagkk8F8N1zAx3REyqbNtdto7CTJ/LMEFW7UxRqgg5 02Ew== X-Gm-Message-State: AElRT7Gx7UY8PpopKDGPMx0THwL4rqRINOb1C2YtTRo1mB82EpxGhk6I Rg9i6A6Bgk3B6Io8HhtXkEeHdA== X-Google-Smtp-Source: AG47ELv9XfgGCDmmWm38ZokuGuM2+W6U8UxWaidUYZnZEkz9ZzMmTObN/BASuD6icjfe1Cy9AXKOjg== X-Received: by 10.200.35.46 with SMTP id a43mr4126364qta.311.1519923972411; Thu, 01 Mar 2018 09:06:12 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id g54sm3242296qtk.43.2018.03.01.09.06.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 09:06:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <6337AD1B-D1A8-4D3F-8890-A36ED46B47D9@fb.com> Date: Thu, 1 Mar 2018 12:06:08 -0500 Cc: "mls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <6337AD1B-D1A8-4D3F-8890-A36ED46B47D9@fb.com> To: Jon Millican X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2018 17:06:27 -0000 Jon thanks for bringing us back on topic. spt > On Mar 1, 2018, at 11:59, Jon Millican wrote: >=20 > If the question is about whether MLS should support forward secrecy in = the first place, I think consumer E2E messaging applications provide a = good use case for this. The threat model that we tend to take here is = that the user has limited trust in the service provider. In this = situation, the security properties provided by TLS are almost moot, as = TLS only protects you as far as the service provider anyway. > =20 > Ephemerality is a very common property in such apps, with the explicit = goal that messages not be accessible after a certain period. Even = without ephemerality, I believe that most messaging support message = deletion. In such situations, forward secrecy is very desirable, as it = ensures that if keys or any device state do leak at any moment (be it = from an exploit, somebody imaging a device, or a temporary bug in the = app itself), users=E2=80=99 old messages can at least remain secret, = even if the provider had retained all of their ciphertexts. This also = leads to a similar case for Post-Compromise Security, in that secrecy = can be recovered even after any sort of key leakage: although in this = case the argument applies even when no messages are ever deleted. > =20 > On 01/03/2018, 16:35, "MLS on behalf of Phillip Hallam-Baker" = wrote: > =20 > On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley = wrote: > =20 > Generally, I think the right answer to these, however, isn't to modify = the messaging protocol but rather to add that functionality on the = messaging app over the top. That also is a much easier way to do new = device history sync > =20 > This is similar to the approach used in some email environments. The = email message is decrypted for reading, and then encrypted in a separate = archive key for storage. > =20 > Russ > =20 > =E2=80=8BIt is a valid approach and it might be the right approach. > =E2=80=8B > =E2=80=8BBut what we have right now is a rather complex proposal that = may or may not be correct and may or may not be addressing the real = requirements and may or may not be addressing them in the most = straightforward fashion. > =20 > So far I have seen a lot of defensive responses and one individual = whose behavior was bullying. Now the fact that I cannot be bullied out = of my opinions does not make =E2=80=8Bthe experience of people making = personal attacks any more pleasant for me.=20 > =20 > More importantly, I am concerned that what has been more or less = explicitly stated is 'we have our proposal and if you don't like it then = bog off'. > =20 > I don't think that language encourages honest debate about the = limitations of the proposal or identifying the flaws.=20 > =20 > I would much rather the IETF endorse no proposal than one that only = navigates the process because a group of bullies shouted down anyone who = was critical of it. We saw that happen with DANE we saw it happen with = CBOR. CBOR does work but the consequence of shutting down the voices = saying that we needed a binary format that precisely matches the = semantics of JSON is that we had to spin up a separate COSE working = group to repeat the work of JOSE rather than simply apply the encoding. > =20 > =20 > The assumption of most here is that the requirements are easy and the = cryptography is hard. That is precisely the wrong way round. If we = really understand what the requirements are, the cryptography follows = almost directly. It is getting to the understanding of the requirements = that is the hard part. > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Fri Mar 2 01:46:02 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBED1270AE for ; Fri, 2 Mar 2018 01:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozH2pK91sl39 for ; Fri, 2 Mar 2018 01:46:00 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3FE412702E for ; Fri, 2 Mar 2018 01:45:59 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id g72so12505858lfg.3 for ; Fri, 02 Mar 2018 01:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=01pw3v22B9VypiIWXlCR086k22CkO/O/FGfspxgzkK4=; b=DJmlx4DcsAerIC5DMBpHEh3TWQKgOB0HlU6VoIy2U9TNVDpDGpyveXBbshf54+edvK Q39fFz2WtKGZ2oucuONN1XBPkbkkVmarZSf7QrdH5awS6HzkIalceD5cPjVq+I5Lv0AU pqYbi+eN3tCYYe6E4uLmy8jGG5Ob0nanruSz4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=01pw3v22B9VypiIWXlCR086k22CkO/O/FGfspxgzkK4=; b=rE3dqWmV8M3+K4EhjVCUXNWdKrI5WqoikZvLEsImYl8NUXgujn+mnHfaW8EfTTPDs8 myJw5vhCFMAzRxvU4Tnid7/vJkkmV76EAfdUnzGM9s0E9MmIdfvvCXa1EDCoTjm58US8 dsD3Tc1RYuph0p4YIcp9411X+6TUPMhrpkF33cnveValJtDEb4mxGnwid8FWaiWWXBNn 76xTSA0kd8PeKgKJpgkbI3DjqAOx4tYmRpEchjP41O95VTqgvTVZrC/X4HuthAl2AYsg /irqp+R07eIUj7QnVweoIdYwPh5IerOQoaTvHNW8U9p8T1yXf39k+04V+Ql0UBWFmVjY wp1Q== X-Gm-Message-State: APf1xPDEMovXGKUySJjp/eHRRADxbcvdZSRDMZYDwOpwgFPRT/2tKZL7 Ti3CHKVd7Esg6bj22R0uktEo7cfYrIHotG1GMhKwyg== X-Google-Smtp-Source: AG47ELuv5vQf7T46Fby2axTVo0vOQ+F7yo8QEWJRpFS1+qR6WDmrfs37n7HQligUNnbeyDud7K7w07BzOzMb1vkyHoE= X-Received: by 10.46.124.8 with SMTP id x8mr3390399ljc.121.1519983957915; Fri, 02 Mar 2018 01:45:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Fri, 2 Mar 2018 01:45:57 -0800 (PST) In-Reply-To: <6337AD1B-D1A8-4D3F-8890-A36ED46B47D9@fb.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <6337AD1B-D1A8-4D3F-8890-A36ED46B47D9@fb.com> From: Dave Cridland Date: Fri, 2 Mar 2018 09:45:57 +0000 Message-ID: To: Jon Millican Cc: Phillip Hallam-Baker , Russ Housley , "mls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 09:46:02 -0000 On 1 March 2018 at 16:59, Jon Millican wrote: > If the question is about whether MLS should support forward secrecy in th= e > first place, I think consumer E2E messaging applications provide a good u= se > case for this. The threat model that we tend to take here is that the use= r > has limited trust in the service provider. In this situation, the securit= y > properties provided by TLS are almost moot, as TLS only protects you as f= ar > as the service provider anyway. Well, I think TLS is important too - it's usually protecting metadata from third parties to a reasonable degree. > Ephemerality is a very common property in such apps, with the explicit go= al > that messages not be accessible after a certain period. Even without > ephemerality, I believe that most messaging support message deletion. In > such situations, forward secrecy is very desirable, as it ensures that if > keys or any device state do leak at any moment (be it from an exploit, > somebody imaging a device, or a temporary bug in the app itself), users= =E2=80=99 old > messages can at least remain secret, even if the provider had retained al= l > of their ciphertexts. This also leads to a similar case for Post-Compromi= se > Security, in that secrecy can be recovered even after any sort of key > leakage: although in this case the argument applies even when no messages > are ever deleted. And yes, I totally agree with everything you've said here, which can be summarised as "FS is important in consumer-grade messaging". But: * A verifiable record is more-or-less mandated by Government. * A verifiable record is generally relied upon by consumer service companie= s. * A (non-verifiable) record is used in most enterprise messaging applications, and many consumer grade. * Consumers sometimes talk to consumer service companies and Governments. Again, I'd make it clear I am not arguing that Forward Secrecy should never be available - I'm arguing that in some cases it may not be an acceptable option, and in such cases if the options are between non-viable (but good) security and no security at all, then people will simply choose another option (like a bespoke messaging platform for enterprise/consumer). That feels like a missed opportunity. Dave. From nobody Fri Mar 2 01:51:05 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A81127342 for ; Fri, 2 Mar 2018 01:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xciqjvD0h1kN for ; Fri, 2 Mar 2018 01:51:02 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D49112702E for ; Fri, 2 Mar 2018 01:51:02 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id f75so12523850lfg.6 for ; Fri, 02 Mar 2018 01:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BgLy53/De+F4DTb6+7h/S06oPP6wc4ARFnTYCALXRUs=; b=DxIBodmJlwCIWj46grOL8ikEh1GZRJ8oAjl1mQ/3GFBo0VvsDat5VByanXZRA2kIF2 YjtRDDH65C90Rv4ViWt4wfsQOSXBxxHnsHlwrFtBPovTo+gndlA1NqzB31Y9HdJg57AL MxE0XCmATgz0SWT7QZnV1AikyLL09s605LL/A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BgLy53/De+F4DTb6+7h/S06oPP6wc4ARFnTYCALXRUs=; b=ZyBzDf53yt1AEbrR9kOiU54Gw3HyqF4rUKv0+DHOyhrQo+pJTqLJPH3WxNx9Au2jjN 0gJ4BDSyI77dqCBL9To8j8HPat3eESAF33VmX5qhvTap2GRjFIdK0mEs9Os1ev40e9ep Cw8iKSai7cIpKOBr0qONh6nfVVgFZhxt4z47fFtbKedAw1PnxT8u7HDywXtS0FtN3ySS ILDivWp7MhU6IM5j6xcewAwJzoeARK8s/EhpG0ZK1hAdLSaG2XKbcHyt51I+V55dRX4J d/dzbDjDzPluY2R9SCsWku7czWm10u/BoBMl9oUyiSQmlbBNk0n+iGot7I47mdMBlYgX O5FA== X-Gm-Message-State: AElRT7HeyDFuSqFFqtmp7td8joP4cn3C/9vLvfCIU+BrcqOoRXe04pkz sFI+Z12/DErpRnQrE3/6Djx24bf1Kj5w6+iPshW394Mz X-Google-Smtp-Source: AG47ELtcO3Wx/EWxkKe3mBb37MZBCg8qN7LbA6aWDWrt0D99OSPvO3hXbqGbX5UyEtBlxS0I0/6NOEbM5T/OtunekPs= X-Received: by 10.25.26.130 with SMTP id a124mr3203450lfa.35.1519984260394; Fri, 02 Mar 2018 01:51:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Fri, 2 Mar 2018 01:51:00 -0800 (PST) In-Reply-To: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> From: Dave Cridland Date: Fri, 2 Mar 2018 09:51:00 +0000 Message-ID: To: Russ Housley Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 09:51:04 -0000 On 1 March 2018 at 15:11, Russ Housley wrote: > This is similar to the approach used in some email environments. The email > message is decrypted for reading, and then encrypted in a separate archive > key for storage. Sure, but that explicitly means that messages within the archive can no longer be authenticated, doesn't it? That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For all its faults, that is providing a secure archive that the enterprise has access to via an offline key escrow. If I'm wrong here please don't hesitate to correct me. Dave. From nobody Fri Mar 2 02:08:29 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E6F1243F3 for ; Fri, 2 Mar 2018 02:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=yBTWkxAf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ep85nhEb 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 oJTD1mAd0pAy for ; Fri, 2 Mar 2018 02:08:26 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AE1120725 for ; Fri, 2 Mar 2018 02:08:26 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9BE2B20FAB for ; Fri, 2 Mar 2018 05:08:25 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Fri, 02 Mar 2018 05:08:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=RGFy6n7iinkTFuxkdcuXJ7wGAg 5NCOugv9XoQNNKyug=; b=yBTWkxAfr2Q0o4Z12HqZN3WHusNdDAq9/RA3HPW0nx FPcfbTkBFC3eBKJlNQDOnXDc7jxWQotYKKzP5m5OwC/3pP4/Y17aXs0slTRc00ZH CLmuH54WAtV+tBCzcZSZW890MjHWIpkF0u9IyIb4AV/TFVW5pKBpWUbQ7+k0dz/q c= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RGFy6n 7iinkTFuxkdcuXJ7wGAg5NCOugv9XoQNNKyug=; b=ep85nhEbaMcTNF4qmBgDG2 DyGgFW8K211eR+YgTZ0vu1Ne8OFjSBEDQqUvA5BPUn+3ALXc8BnG0+f5j4YBDhIC PN/YWbioXBTTWeeSq8EBWoPbFFtm+x62o6UF0dJXbZbDDpDXgCQEy51AyR19OF+8 4trRoX8OvCmgafVXQtxaWjexfKGpvNUK9w2BzuGCX0Rio4aAu20wj+Dn3mPrDPHb 4XtoqdWCwcZAnMH8Ths5dtj+Ytl41zZENjmoDAjKNe1ISUDvwAaSDjhsddt/B381 0DGnczKU3SHScJwecVt+uV5ZRFMj1Ipay7gtru8bucthe7TO6lRD6d2rv2GKjSAQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 79EE542B4; Fri, 2 Mar 2018 05:08:25 -0500 (EST) Message-Id: <1519985305.3968823.1288911184.1B5A3562@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 In-Reply-To: Date: Fri, 02 Mar 2018 10:08:25 +0000 References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 10:08:28 -0000 On Fri, 2 Mar 2018, at 9:51 AM, Dave Cridland wrote: > Sure, but that explicitly means that messages within the archive can > no longer be authenticated, doesn't it? Do e.g. governments require that the archive consist of the actual encrypted messages that were transmitted over the wire? As opposed to having a trusted party, perhaps a "recorder" group member, re-encrypt them for archival. From nobody Fri Mar 2 02:55:20 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FE2124B18 for ; Fri, 2 Mar 2018 02:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DC0DTuGUmncL for ; Fri, 2 Mar 2018 02:55:17 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2FC120725 for ; Fri, 2 Mar 2018 02:55:17 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id 70so12763072lfw.2 for ; Fri, 02 Mar 2018 02:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NbyzIlqFJJ9MfFVCgXw2CieDq528x7qfYthr/YTVtgM=; b=NsdeZdU3suUr4eyXjWWk9hOUM82bfqVWX6NzoysBSPvdXUDGdOMK/NEvLQ8A1RqGVh xAhLn+5vV9mMTKGLZw/YaZ1YuCl1tRfvzg/8dDVMDMsebb2DlsomOHwf1Zb7lI/5DrYX 56GCRatHxieSHDGwKCSPJEZ3ttc663Oh0hWBI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NbyzIlqFJJ9MfFVCgXw2CieDq528x7qfYthr/YTVtgM=; b=IwUyfVog9R6arrqdfS7r3bXnkScWrz16xJoKblcoPjRTo6zWOXBx+VP8183gpYwl5x /Ryte496iwlu175lfrgUXt+EOw7TFYehwqJg4KduI/D1PLqqxyhAdxo+rAMR7oBkOAqo vPzXJXH59Qrw2cjrYm3gSf7yIGC1G/PI+pKBarGCRcBwLHsLDvOuTaUf3G63MVYj+5VU f5j/o2B8FnVfNA/P/ku/7zC1UuZf/87MX+1gH1Lm/LD/elQDUMSFCT96C0uqlkkYTwp0 IiBG83uMBTBChOTZSWW52foNFEuYOFKO+VXtXbroHr705oeqYOYPW0Sl/69AchN1v1En qFBg== X-Gm-Message-State: AElRT7FHBLmh+a89R7HrQnCSybWqd4jfa0KqgliJt2Z+MUQJgrvBT8go lqtfhiqL/1yqcpAFOINeoXbx9Fmm0iCqC7eQci4RQa4/ X-Google-Smtp-Source: AG47ELtDE9Xfeuwazbv4+Anq4IX2m+yMV518Vci7uy1JwK1rPKMMtADDWRDiGq+N8r6gaTZfFmDB00O1GrkPkYbH5PI= X-Received: by 10.25.59.79 with SMTP id i76mr3677420lfa.28.1519988115526; Fri, 02 Mar 2018 02:55:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Fri, 2 Mar 2018 02:55:15 -0800 (PST) In-Reply-To: <1519985305.3968823.1288911184.1B5A3562@webmail.messagingengine.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1519985305.3968823.1288911184.1B5A3562@webmail.messagingengine.com> From: Dave Cridland Date: Fri, 2 Mar 2018 10:55:15 +0000 Message-ID: To: Katriel Cohn-Gordon Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 10:55:19 -0000 On 2 March 2018 at 10:08, Katriel Cohn-Gordon wrote: > On Fri, 2 Mar 2018, at 9:51 AM, Dave Cridland wrote: >> Sure, but that explicitly means that messages within the archive can >> no longer be authenticated, doesn't it? > > Do e.g. governments require that the archive consist of the actual encrypted messages that were transmitted over the wire? As opposed to having a trusted party, perhaps a "recorder" group member, re-encrypt them for archival. Pass. Currently the NCSC won't accredit any solution not based around MIKEY-SAKKE for OFFICIAL and up, but - rather like MLS, actually - we have a bunch of security outcomes but no indication of what drove the decision, or indeed what's important. Dave. From nobody Fri Mar 2 06:52:05 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A035127444 for ; Fri, 2 Mar 2018 06:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE7hZi7mtWjC for ; Fri, 2 Mar 2018 06:51:50 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 1E5EC12DA15 for ; Fri, 2 Mar 2018 06:51:50 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id z197so12202922qkb.6 for ; Fri, 02 Mar 2018 06:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=46Ueq1t2sMqOkfF2ApboqCu4vJuTN+uupxyN+XEIXrg=; b=FoYHtei2LBD8tknjcF+9a5BkIOqdnbpUFrzCmrafOXFAlLgUmQTmNyzxRAnyv4wPkr yzkBKLAEjIg1jS8nZY9VgR7hSjvUH+xDyHl380/6tPuwFVZmmUe7bZJvdYCFjnxBAwRr CzaAnhO2704NGaEX+ECMeWR9Ag03/LYYm3/KOSEId+PRtSsCEovTsYIcePQ+lpsqGndn z+YYdZh0Qg6OZyWPExiwy4G+NL2NKVlvP6UDR+abq58SNspzq71GfmOJfNXM6cXmGQ71 eyPHp9NYktb37KRm5DDvaYMnPsOTuV5ls+wjKCetK//5lXtHpMlwtq9D1wWpgYJDJ6vu rd+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=46Ueq1t2sMqOkfF2ApboqCu4vJuTN+uupxyN+XEIXrg=; b=FUFjNgmc+4XBHJJXaN2z0TNhDwZ1+4MlPjHHlIFcz5FaX3JlRIT9XkV/zCAlmgb8Xi r/bDoGzp6X10nMmF1zQzrM/PvMDmvQFvj1ClQgHpBMHo1EaKP3y/3x5IRQHXTqsb/y6g ++3ntFsCuXdEPA0f2REx5fqAjOCR/leNaBxUgp8yykV/7AFx3w3YbPQIfSiHZfeFk6p/ LbI1Zinp3pJmf1a24FScJ294IRfWRgti4V1SfR3Rqlbpz/kng8ApwbDL66PwSBw/yZZT XwCfjYbtgxLdhODNeCE+U0eLs0A0WN3ott5MYFYUxkRpFq+LcDzPhvunig8wXV8qfq2r 9r0g== X-Gm-Message-State: AElRT7GLYyYBUKYUcIT5y7VfQbKhsk05JOci3vIWxeuUiz/0qeaPNI5r 0mN2nourhDSLBa3tfEVIlH54aEs+QcpcPBSMHw2O0Q== X-Google-Smtp-Source: AG47ELtK4jZIggCUviuAKAn5UK8ILtWaAg2IqWo7bZrSOoLoZP+2OB8osfY9fik6tjSpJh8O+4TbsSXPTVszF1VVN8w= X-Received: by 10.55.221.198 with SMTP id u67mr8676516qku.91.1520002309155; Fri, 02 Mar 2018 06:51:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Fri, 2 Mar 2018 06:51:08 -0800 (PST) In-Reply-To: References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> From: Eric Rescorla Date: Fri, 2 Mar 2018 06:51:08 -0800 Message-ID: To: Dave Cridland Cc: Russ Housley , mls@ietf.org Content-Type: multipart/alternative; boundary="001a114992e0b210c905666f1d6d" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 14:52:03 -0000 --001a114992e0b210c905666f1d6d Content-Type: text/plain; charset="UTF-8" On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland wrote: > On 1 March 2018 at 15:11, Russ Housley wrote: > > This is similar to the approach used in some email environments. The > email > > message is decrypted for reading, and then encrypted in a separate > archive > > key for storage. > > Sure, but that explicitly means that messages within the archive can > no longer be authenticated, doesn't it? > Not if they are digitally signed, which is an explicit option in the current drafts. -Ekr That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For > all its faults, that is providing a secure archive that the enterprise > has access to via an offline key escrow. > > If I'm wrong here please don't hesitate to correct me. > > Dave. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --001a114992e0b210c905666f1d6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland <dave@cridland.net&g= t; wrote:
On 1 Ma= rch 2018 at 15:11, Russ Housley <housley@vigilsec.com> wrote:
> This is similar to the approach used in some email environments.=C2=A0= The email
> message is decrypted for reading, and then encrypted in a separate arc= hive
> key for storage.

Sure, but that explicitly means that messages within the archive can=
no longer be authenticated, doesn't it?

=
Not if they are digitally signed, which is an explicit option in the c= urrent drafts.

-Ekr


<= /div>

That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For all its faults, that is providing a secure archive that the enterprise
has access to via an offline key escrow.

If I'm wrong here please don't hesitate to correct me.

Dave.

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

--001a114992e0b210c905666f1d6d-- From nobody Fri Mar 2 10:15:04 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B368B12D871 for ; Fri, 2 Mar 2018 10:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b=J+1OumYl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RfCaRm3M 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 qrFlJpf9fKU3 for ; Fri, 2 Mar 2018 10:15:00 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB12812D7F2 for ; Fri, 2 Mar 2018 10:15:00 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 063FE20B4D for ; Fri, 2 Mar 2018 13:15:00 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute1.internal (MEProxy); Fri, 02 Mar 2018 13:15:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bErrBW+x3b/UkUcZs DpeZNo8PuLbTAHfZ6fkSsjqu2w=; b=J+1OumYldZx0JVA7GJ23aka0UKqNBk/9R i0Lc0OkY48mD56xIulxNh2A3K+LFUqiODjNnZG8HRuQPZ0z3AdfNJrxiLi9o8Lm0 axko4pjw99FGOogXCjF3yRT7yVZ7+hYVzqIgf7+upchWuOQ9Y6v3B04jUYMbQ669 TZJ90dXd7PtLCtGJOrkwFTJZlWzyFjQSW6Fp0nTDTCSpXT/y9l6BmcDDKuDoc2o8 ETrP6jmRTRqAdZ2YQr0EDytWSFBqk3kdP9KgIWk80DmlZmHWV2kBl2Is2hKYoNGg ++AyLO46yWyw2qKB5nXaf6iNj4Yrx5CLQXUgyr6+URg7Em0fB9ouQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bErrBW +x3b/UkUcZsDpeZNo8PuLbTAHfZ6fkSsjqu2w=; b=RfCaRm3MdW65MdX/oJbTWV p7uUIOlLCyFP03ISycnGoucuK0lm7rXTrsVrCQTocCb1wfumUmMRsKCopT1nGzR2 lIfFqLu4X8k8cJwO3uaSl2q1YH8wCD6i21cuX60AdN8ww5iFNHwt3Hf+4YSUxyjx MQ/NXVlI4+gWbmr8Og8b9u3ptXOY0xCsFlTVSNKpTZJWtLQCfdYn5EbFcQjYAuOu 9KWYHm8UY+R/NCdkMSEn7jXNCcazhxMehGDCx+2mfnVRDIx7Z/IN/F8ZObvM2pOi InpEiGet7KN56Fjsa3xGxp8xbotsIY/wk7F9TrihUuo4Hz32RoO37Sdg7G5SsUsg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C5AAB9426A; Fri, 2 Mar 2018 13:14:59 -0500 (EST) Message-Id: <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> From: Nadim Kobeissi To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-b08ff009 In-Reply-To: References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> Date: Fri, 02 Mar 2018 19:14:59 +0100 Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 18:15:03 -0000 There is a small body of contributions I have regarding this discussion thu= s far. They are organized below in a set of more general comments, followed= by specific responses to Phillip Hallam-Baker. A1. Moving forward, it's likely just better for us to refer to forward secr= ecy as forward secrecy. The "perfect" suffix, historically, largely exists = for anecdotal reasons and has little to do with the actual concrete meaning= to the term in reference to its security goals. "Forward secrecy" and "fut= ure secrecy" are confusing terms anyway: for one thing, they seem to refer = to the same property, although they are diametrically opposed with regards = to the chronological direction in which confidentiality and key freshness h= old, post-compromise. A2. As alluded to by Denis Jackson, asynchronous forward secrecy is documen= ted by the Signal protocol. As far as I know, the earliest existing design = that does this asynchronously is NAXOS [0], which I believe was cited in ea= rlier drafts of the Signal protocol specification anyway. A3. With regards to retention, I think EKR makes the best point in saying t= hat these are use cases best addressed by features implemented by the clien= t application itself. This rhymes with Dave Cridland's original mention tha= t business users are those who most require this: business users are also t= hose with the most tailored client applications, usually, providing ample r= oom for archiving features that do not necessarily affect protocol security= goals or expose MLS to a riskier threat model. A4. With regards to compliance with, for example, MIKEY-SAKKE, it is worth = thinking about whether the entire MLS effort remains as worthwhile were it = boiled down to that common denominator. MIKEY-SAKKE (and company) are by de= sign allergic to strong security guarantees. Phillip Hallam-Baker is correc= t to note that strong security guarantees are not our explicit goal here, b= ut rather a tangential goal to securing MLS use cases to the fullest possib= le extent. That said, as noted by Jon Millican, any run-of-the-mill secure = messaging application today, be it WhatsApp, Signal, iMessage, Facebook Mes= senger, Google Allo, Viber, Wire, or Threema shows an obvious preference fo= r ephemerality and resistance to scenarios where the mobile phone, an incre= asingly disposable device, gets lost, stolen or traded away. A5. As someone who's been involved in secure messaging for some time, I ca= n say that it's by no coincidence that Signal was designed to focus so stro= ngly on both forward and future secrecy. The designers clearly went to grea= t length to keep these properties, and, in implementation, modulate their r= esilience against an unreliable (choppy, weak) network by keeping a certain= number of pre-key hash chains locally. The more hash chains are kept, the = more out-of-order messages are tolerated by the wider the post-compromise w= indow. To my knowledge, WhatsApp keeps a larger local set of hash chains th= an, say, Signal or Cryptocat, in order to account for its larger user base = who may have a smaller tolerance for failure. As a matter of fact, Signal a= s an application evolved away from using pure OTR into designing and using = the Signal protocol largely in order to improve upon forward secrecy specif= ically, adopting an asynchronous forward-secure AKE and a ratcheting scheme= that handles two-party key contributivity much more quickly than OTR. A6. I think it's doubly more important to consider adopting EKR's suggestio= n, discussed in (A3), to its fullest possible extent because of the negativ= e impact that accommodating against forward secrecy may have towards enabli= ng downgrade attacks that chip away at forward secrecy. Once this is ingrai= ned into the protocol, we may end up having to give an active attacker much= stronger grip over when, and even if, forward secrecy ever kicks in. Some responses to specific claims made by Phillip Hallam-Baker: PHB Statement 1: "Alice works in a team with Bob and Carol. At some point D= oug joins the team. At that point, Doug needs access to all documents and d= iscussions related to the project." Response 1: Especially given that this seems to potentially require expandi= ng the MLS problem space to document access, it is definitely best to follo= w EKR's recommendation, as mentioned above in (A3). Not only does this prov= ide appropriate document access irrelevant of forward secrecy guarantees of= MLS, but it also segregates key retention to involve only documents that m= erit such retention, and from a software engineering standpoint is likely t= he most elegant solution anyway. PHB Statement 2: "If Alice creates a message for Bob using only her knowled= ge of Bob's public key then it is not going to be PFS because a compromise = of Bob's private key is a breach." Response 2: The consequences of the secrecy of the very first message in = a Signal session, given a long-term identity compromise, are not as you des= cribe. That is because you would also need to compromise Bob's one-time pre= -key, which is erased after the AKE concludes. The consequences of both the= se kinds of compromise are modeled and documented by Katriel's Signal paper= , as well as a contemporary paper published by our team at INRIA. PHB Statement 3: "In general, I like to see what the requirements are befor= e jumping to implementation." Response 3: It is quite likely that any current implementation of MLS isn't= very fruitful. Better to discuss more first, especially at the upcoming me= eting at IETF 101. PHB Statement 4: "This is a different problem to TLS because we have more t= han two parties and it changes matters." Response 4: The manifestation of the problem is what is different. Not the = problem itself. The problem is layer security. TLS had to implement forward= secrecy in order to have a meaningful answer to that problem. In messaging= , the problem of layer security is the same, but manifests itself in a diff= erent medium. Forward secrecy is in all likelihood still necessary to offer= those affected by this problem the level of security they require given a = reasonable threat model. PHB Statement 5: "One of the things I only just realized is that PFS is not= even a property of the protocol, it is a property of a key in the exchange= and not of the exchange itself." Response 5: Either this statement is incorrect, or all peer-reviewed public= ations that exist on secure messaging must be rewritten in order to formali= ze, model and prove forward secrecy on the level of the lifetime of a symme= tric key rather than as a global property encompassing all messages of a pr= otocol. Of course, there are different methods in which to reason about the= same thing: you can see a finite field as a weird squiggly line or as a se= t of numbers, etc. PHB Statement 6: "Let us say that we want FS with respect to each of the ke= ys of Alice, Bob, Carol and Doug but =E2=80=8Bthey don't all want to inject= fresh FS information at the exact same time. Let us say Alice has her key = in a HSM while Bob is using a soft key, Alice is sitting in a SOC and Bob i= s a field agent on Moscow Rules. Bob probably wants for FS their key every = ten minutes. Alice might be good for a week." Response 6: In a protocol such as, for example, Signal, such a discrepancy = can be managed by the participants without affecting the protocol's impleme= ntation logic in any way, further supporting EKR's suggestion described in = (A3) and touched upon previously in the response to PHB Statement 2. References: [0] https://www.microsoft.com/en-us/research/publication/stronger-security-= of-authenticated-key-exchange/ Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office On Fri, Mar 2, 2018, at 3:51 PM, Eric Rescorla wrote: > On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland wrote: >=20 > > On 1 March 2018 at 15:11, Russ Housley wrote: > > > This is similar to the approach used in some email environments. The > > email > > > message is decrypted for reading, and then encrypted in a separate > > archive > > > key for storage. > > > > Sure, but that explicitly means that messages within the archive can > > no longer be authenticated, doesn't it? > > >=20 > Not if they are digitally signed, which is an explicit option in the > current drafts. >=20 > -Ekr >=20 >=20 >=20 > That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For > > all its faults, that is providing a secure archive that the enterprise > > has access to via an offline key escrow. > > > > If I'm wrong here please don't hesitate to correct me. > > > > Dave. > > > > _______________________________________________ > > 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 From nobody Fri Mar 2 12:27:08 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E281412D7F1 for ; Fri, 2 Mar 2018 12:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHTVA63eg24J for ; Fri, 2 Mar 2018 12:27:06 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 50E6F126C25 for ; Fri, 2 Mar 2018 12:27:06 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id 70so15068543lfw.2 for ; Fri, 02 Mar 2018 12:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p6Rdh+Lig5zLeiE6c4a80pCVCOjCdplVEOzQA5mIQ9U=; b=IFkCdyDa+IAw16w/rQ49JL02Imi2kAUKf2NXU3lgL2hlHXLpZqZnXekyQZhxMoXawi SNpjC5q0gUu1DJZNNdduxpaK5e47Sw/xhtN7cImNIiynllBkEH/JzZnhPY9MB+V4r3gi Aw1ivtCcoYzHy5G/84ue+VwqJwlrtYaLNPmUI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p6Rdh+Lig5zLeiE6c4a80pCVCOjCdplVEOzQA5mIQ9U=; b=CHcAWylYCBt93IzoSX7gU0cZ901rGz6r6v9fUAbgsHNWotcHHwyWqWA80PYQZoG9z9 LPzWnTaTU9x7moNNkLLP0Wx+JkG9gUb62EApnWD0A7xkcvGvXjCq8cC23L8UieZZxR8/ PiDIorv+fHcOIZEVZkWs6adNAtm7fgq/VyU8tii39V8QQFKYuMB1hn5IWVD8alTKEeZI 9zwaBpMvVp9jFOqGTOHjBQM7bJ9v3KmTwxu5jG6zZbNzUiwnLe0hC78xtNeZ2FhNpeWb nfOrYnYcxx7nYOKJbywfh3VLJ0Fbr8AQad2tY8JK/Kj+M4I+vx/7zr3LLuBvTjOCkgRY 5D3w== X-Gm-Message-State: AElRT7GwWsu6D3z9DoaLKUz0BiGAhNc7yxaKW5mCA8jSkcEsfRwt4uPP 7Io++HaxzJwJdJfu6LryNGpRFnAMRDsGNb+3P2jav0YJ X-Google-Smtp-Source: AG47ELsiUsVzN3vxtHcnt666cjCDdSM6fNbsRopHz8FLdEA7h3Rk/qTtDMb8v8DK5dfE/HV5rlij104XA2ul7OVKX4A= X-Received: by 10.25.26.130 with SMTP id a124mr4299557lfa.35.1520022423189; Fri, 02 Mar 2018 12:27:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Fri, 2 Mar 2018 12:27:02 -0800 (PST) In-Reply-To: <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> From: Dave Cridland Date: Fri, 2 Mar 2018 20:27:02 +0000 Message-ID: To: Nadim Kobeissi Cc: mls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 20:27:08 -0000 On 2 March 2018 at 18:14, Nadim Kobeissi wrote: > A3. With regards to retention, I think EKR makes the best point in saying= that these are use cases best addressed by features implemented by the cli= ent application itself. This rhymes with Dave Cridland's original mention t= hat business users are those who most require this: business users are also= those with the most tailored client applications, usually, providing ample= room for archiving features that do not necessarily affect protocol securi= ty goals or expose MLS to a riskier threat model. After various side-discussions, I'm comfortable that we can address the demands of enterprise and government cases within MLS - as long as we keep a half-eye on it. > A4. With regards to compliance with, for example, MIKEY-SAKKE, it is wort= h thinking about whether the entire MLS effort remains as worthwhile were i= t boiled down to that common denominator. MIKEY-SAKKE (and company) are by = design allergic to strong security guarantees. Phillip Hallam-Baker is corr= ect to note that strong security guarantees are not our explicit goal here,= but rather a tangential goal to securing MLS use cases to the fullest poss= ible extent. That said, as noted by Jon Millican, any run-of-the-mill secur= e messaging application today, be it WhatsApp, Signal, iMessage, Facebook M= essenger, Google Allo, Viber, Wire, or Threema shows an obvious preference = for ephemerality and resistance to scenarios where the mobile phone, an inc= reasingly disposable device, gets lost, stolen or traded away. To be absolutely clear, I'm not a big fan of SAKKE and I think it's entirely unsuitable for the consumer in any form. Consumers generally benefit from FS, and SAKKE's mandatory escrow is just plain wrong in that setting. The properties that interest me within MIKEY-SAKKE are the possibility of a secure archive with offline escrow, and I think we can do that within MLS after discussion. I actually think this is a fairly well-understood requirement, and as such it'd be useful to document it somewhere in the charter. Dave. From nobody Fri Mar 2 13:04:15 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6C12D7F1 for ; Fri, 2 Mar 2018 13:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 P5s3v2uiNIjB for ; Fri, 2 Mar 2018 13:04:13 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4770124F57 for ; Fri, 2 Mar 2018 13:04:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26926BE74; Fri, 2 Mar 2018 21:04:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMLOFJocBoCR; Fri, 2 Mar 2018 21:04:10 +0000 (GMT) Received: from [10.200.0.239] (unknown [193.180.218.196]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B58BABE5F; Fri, 2 Mar 2018 21:04:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1520024650; bh=/Ksfz6nLSpyHFmHZMn0doaNOPii52THrlPyXTzNh2V4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mQlBuVtxA8fdyYuvlRh+QzvFeU7KuKEQcWzo4pBSfIr4w/L1cDAGG7y8LtCHfSK9S PwCxtFIcPAYsemAthdylUYlMHUgOwVk0t4Y1VYnfn0olFvf83V2I0sx9u00nZ8jJYN o/dOtQR2HLVV70SCjb/IvN4lRZsEFYTuJB42qVvk= To: Dave Cridland , Nadim Kobeissi Cc: mls@ietf.org References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <0ddbadba-9669-33b7-2359-1bd042f37927@cs.tcd.ie> Date: Fri, 2 Mar 2018 21:04:08 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="05nyIPK5ZlUIafwVugJEDRmJad5yKhoZS" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 21:04:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --05nyIPK5ZlUIafwVugJEDRmJad5yKhoZS Content-Type: multipart/mixed; boundary="62T3aLwlTmWXY5BuFHuyyONAmJ5voR5gG"; protected-headers="v1" From: Stephen Farrell To: Dave Cridland , Nadim Kobeissi Cc: mls@ietf.org Message-ID: <0ddbadba-9669-33b7-2359-1bd042f37927@cs.tcd.ie> Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> In-Reply-To: --62T3aLwlTmWXY5BuFHuyyONAmJ5voR5gG Content-Type: multipart/mixed; boundary="------------585D45AA52D9E5EF57C74951" Content-Language: en-GB This is a multi-part message in MIME format. --------------585D45AA52D9E5EF57C74951 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 02/03/18 20:27, Dave Cridland wrote: > To be absolutely clear, I'm not a big fan of SAKKE and I think it's > entirely unsuitable for the consumer in any form. Consumers generally > benefit from FS, and SAKKE's mandatory escrow is just plain wrong in > that setting. I agree with you about mikke-sakke and mandatory key escrow in general. (As does the IETF, in RFC 1984/BCP 200.) As a non-nit: I'd much prefer we consider people and not "consumers," but no need to go there as part of this thread - I know what you meant when saying "consumer" above and it's ok in context. However, I do hope work on MLS does not assume the existence of a major "mothership" - if it did, then that'd be bad IMO, regardless of whether a mothership is an employer, government or commercial service provider. (Allowing for the existence of such entities is ok IMO, requiring them is not.) > The properties that interest me within MIKEY-SAKKE are the possibility > of a secure archive with offline escrow, and I think we can do that > within MLS after discussion. >=20 > I actually think this is a fairly well-understood requirement, and as > such it'd be useful to document it somewhere in the charter. Fair enough. The potential that archives can be kept is reasonable, even if the putative MLS-wg/RFCs mightn't specify an interoperable way to do that. Cheers, S. --------------585D45AA52D9E5EF57C74951 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------585D45AA52D9E5EF57C74951-- --62T3aLwlTmWXY5BuFHuyyONAmJ5voR5gG-- --05nyIPK5ZlUIafwVugJEDRmJad5yKhoZS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJambxIAAoJEFqy+vF7FyvqPdQQAMoDKraQPD+78iSo8pvgI49b l6VXT1Bys96hYfjTV6QSN3NfZF+E2JgP3vKABbbxYWmDDGhliBINAUH8t++knZR0 eEYzKcCufjtSDgyCO4wLuHtwHibF2DB5VZD6bL+2AedFy9c7mF3J4QrP37AlKRp5 6TWVA28hUBQ9j8A/ehRvBh68u86/+1iDjEGY026HPq9WCve5eq7dkAoXtK0H4w8I 2OpQ39wy0l+0GErRChKYtGWkpocslNoWFVlf+5W8XkcjWIC8imzNFqeZ76c0DN4J cveG2jaQLK/MpNQvJJntXeMyfgva0YMbhOEkIOcfEEKbGm+Bl3OpzfSU4xIwcxfV n0jR6K2jGKAN2pY7oKDm0ysEDHBp3B4EEDHt4lXjPlpeEGpdeltnZBX2+WFIzXh1 9cuJ3SJHu7Yr02gsqQ3AoM0+pffh2KSwLS1lASF+yYvzFlLTeDwgYxV+TOcOul45 XIrvH2U0mIdXfHyIDqZm0CBfkR45Z4HOwR/Ul1DPoI6OFH76sWP+c7RDymqoGbUt jibIFRGGJ+ysXKSZ8gX5X3p9NUazKdGkEgjifpMOVEufeGr0vSNnymWM/v7Nxhr8 98Q+cjiCusgKIBVmAV7ImlGQTfpgw4cajdztmHS0sp01XbEy8prRriiSP0++wO+W +94QwjeGdDPb7ykM24bj =2Bda -----END PGP SIGNATURE----- --05nyIPK5ZlUIafwVugJEDRmJad5yKhoZS-- From nobody Fri Mar 2 13:18:33 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35659124239 for ; Fri, 2 Mar 2018 13:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU8UOG2Icnb2 for ; Fri, 2 Mar 2018 13:18:30 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8801D12025C for ; Fri, 2 Mar 2018 13:18:30 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id q69so15213197lfi.10 for ; Fri, 02 Mar 2018 13:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tVfPLmmdp5QWh+tJe4qzhBAzvRNS4daph6oBBBZt5+k=; b=YilRls+L9VhzfmKfzGTiHzyTJZtT27PyC4+w5j0k+0If2/mHDfQO3g+p5IgOAmPAUT /qrtM6/ejLXEV17OXWRguZ/OKsHOZgCdWdobgxARTCLbbomlK5J6hYGTItT4FHLkOs7k If/zuT+KMlhoF3i3IMXoRpFvXZjuV8Izu4n24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tVfPLmmdp5QWh+tJe4qzhBAzvRNS4daph6oBBBZt5+k=; b=Wu+4YgMbuxEXoIYxv9ljikbLAMjCZO6g2yLm3KUh3B6jFZE7o/7SD8HgDV6B7qJnH3 rtrLXePpmjXsAOrVFjOnCx1Vs+99boUuqi41cDROabSOkqTnY0idoYhai1Wo4FQCkGy7 GXZ0U13vdb1VBH861yPYEnjKiuEsqzRQXUR7dWHzpk61pcgCJepFw8DfGb9mlK43Okrz a0wZWYF0LkJgErHdYXM4v1uxHYzPQ40laIJsEmxKX2/QVcd6q98o152QP3X27kUIyuDp g8VTxbSiWtSr8Y5hGtyp+ocryWZrRTar5Q8c/C+dLA5UNdoOKs/jl8wCPrwdbU4Oog1E rEnw== X-Gm-Message-State: APf1xPDNbrXNU5Xc/YoM2mAzyGGSKNNCSwt4/N8bSI0fPTvuOeoLvrqS 849AoKQccWcHZ7irUi78hn3Js+v9Bp/zI8pebEPN84QB X-Google-Smtp-Source: AG47ELvmc9U4kJyEBO1R7sZCCdT2C2X9Tg7cGWtYTRY9Jc59rbrKGEcuxm6WpHMsZZb2JdsNtdjezGkb2MDpcozmBtw= X-Received: by 10.46.13.10 with SMTP id 10mr5118531ljn.8.1520025508799; Fri, 02 Mar 2018 13:18:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.26.8 with HTTP; Fri, 2 Mar 2018 13:18:28 -0800 (PST) In-Reply-To: <0ddbadba-9669-33b7-2359-1bd042f37927@cs.tcd.ie> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> <0ddbadba-9669-33b7-2359-1bd042f37927@cs.tcd.ie> From: Dave Cridland Date: Fri, 2 Mar 2018 21:18:28 +0000 Message-ID: To: Stephen Farrell Cc: Nadim Kobeissi , mls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 21:18:32 -0000 On 2 March 2018 at 21:04, Stephen Farrell wrote: > > Hiya, > > On 02/03/18 20:27, Dave Cridland wrote: >> To be absolutely clear, I'm not a big fan of SAKKE and I think it's >> entirely unsuitable for the consumer in any form. Consumers generally >> benefit from FS, and SAKKE's mandatory escrow is just plain wrong in >> that setting. > > I agree with you about mikke-sakke and mandatory key escrow in general. > (As does the IETF, in RFC 1984/BCP 200.) > > As a non-nit: I'd much prefer we consider people and not "consumers," > but no need to go there as part of this thread - I know what you meant > when saying "consumer" above and it's ok in context. I'm using that term quite deliberately, I'm afraid. "Consumers" are not the same as "People" - People act in roles, and one such role is as a consumer. Happy to use whatever terms you like, but not conflicting ones. "People", in general, might find a legally recognisable record of their communications quite useful at times. > However, I do hope > work on MLS does not assume the existence of a major "mothership" - if > it did, then that'd be bad IMO, regardless of whether a mothership is > an employer, government or commercial service provider. (Allowing for > the existence of such entities is ok IMO, requiring them is not.) > Right, totally agree. I think it's relatively simple to ensure that a person cannot have a "mothership", as you put it, imposed upon them without their knowledge, and I think that's an entirely sane goal. (In fact, I think it's met by the current drafts, which is why I'm not arguing for it). Dave. From nobody Fri Mar 2 14:23:24 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD58B126BF7 for ; Fri, 2 Mar 2018 14:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=symbolic.software header.b=dryV9xdn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hq84krGp 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 VRLAQVmNb-iR for ; Fri, 2 Mar 2018 14:23:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1691250B8 for ; Fri, 2 Mar 2018 14:23:20 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E218120D67 for ; Fri, 2 Mar 2018 17:23:19 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 02 Mar 2018 17:23:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= symbolic.software; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ieiS8OQMXg/2P2eZ7 pomib12gF229QlGRE2NbXiRvKg=; b=dryV9xdnDrmpBMTow9gqJ4+VWwMLowKyx 21zeNU5jVD+a7hAHmFIvGMnpfU6BXdSFDBIT6CPlAhYSPU8yCA2kAwoqwNtBjlCu nWjgluHzJVJWEsQzw4oTMKMjmAqLieINuCaDRi7ZqpkJvpg9DabtgCr0YyBilP7V TNmbdQt4p6aoi0LItiZvBedLkxHR8qETB0aItg+Kl3VIR6hubRi8drZ2uMyuL4JW 43RYTQ48FuMJkhBI+vKMI5my7+H8WkojjFYn8OleGmCrR1Pgxd+nX5L6LxeHnNks OVBuMB3IhFeYJtwT+dxe52aVy/OAvBxQxMnFFgXm7OaCEEXtmarnw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ieiS8O QMXg/2P2eZ7pomib12gF229QlGRE2NbXiRvKg=; b=hq84krGpK5yhxfSqI3Havc +upTZAaTMuwzufcMpN4bEQNXCs/7ujoss5dL2io7YTTXA23uiZV7wTOI5CY167nx +0ILf0b/lVmXCpe6NYi5D3xgwnzTFIAJTWlXTg0ZWJcA9oYjE8YqQ3q4LSWrnsm5 OqSfOv2gj2kIakrMXmnGKTZ41leRyrVWVo/Ek079WmRBngzv964JJxuWfPeFMt4/ jrgJ3CTymx5Ijn8yqFwlRu9/kIlpA8SH3secrjfRrQMyQ3H2Fq+jGgPp+7YDG9ML 3MnCHWGh7yeQ4jEVDQgt7CtBWl3zbndRywNLx6uYfsGPGN+L+4RypEaq7uNeyscw == X-ME-Sender: Received: from [192.168.1.12] (lfbn-1-478-154.w86-245.abo.wanadoo.fr [86.245.184.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 7796A24880 for ; Fri, 2 Mar 2018 17:23:19 -0500 (EST) From: Nadim Kobeissi Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Fri, 2 Mar 2018 23:23:17 +0100 Message-Id: <388D82D4-9B55-4A37-99E7-A42C9DB95E11@symbolic.software> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> In-Reply-To: <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> To: mls@ietf.org X-Mailer: iPad Mail (15D100) Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2018 22:23:23 -0000 (Small correction: my reference to the NAXOS AKE was off, I was misrememberi= ng its contributions and should have rechecked the paper before citing it.) Nadim Kobeissi =E2=80=A2 Symbolic Software https://symbolic.software Sent from my iPad > On 2 Mar 2018, at 7:14 PM, Nadim Kobeissi wrote:= >=20 > There is a small body of contributions I have regarding this discussion th= us far. They are organized below in a set of more general comments, followed= by specific responses to Phillip Hallam-Baker. >=20 > A1. Moving forward, it's likely just better for us to refer to forward sec= recy as forward secrecy. The "perfect" suffix, historically, largely exists f= or anecdotal reasons and has little to do with the actual concrete meaning t= o the term in reference to its security goals. "Forward secrecy" and "future= secrecy" are confusing terms anyway: for one thing, they seem to refer to t= he same property, although they are diametrically opposed with regards to th= e chronological direction in which confidentiality and key freshness hold, p= ost-compromise. >=20 > A2. As alluded to by Denis Jackson, asynchronous forward secrecy is docume= nted by the Signal protocol. As far as I know, the earliest existing design t= hat does this asynchronously is NAXOS [0], which I believe was cited in earl= ier drafts of the Signal protocol specification anyway. >=20 > A3. With regards to retention, I think EKR makes the best point in saying t= hat these are use cases best addressed by features implemented by the client= application itself. This rhymes with Dave Cridland's original mention that b= usiness users are those who most require this: business users are also those= with the most tailored client applications, usually, providing ample room f= or archiving features that do not necessarily affect protocol security goals= or expose MLS to a riskier threat model. >=20 > A4. With regards to compliance with, for example, MIKEY-SAKKE, it is worth= thinking about whether the entire MLS effort remains as worthwhile were it b= oiled down to that common denominator. MIKEY-SAKKE (and company) are by desi= gn allergic to strong security guarantees. Phillip Hallam-Baker is correct t= o note that strong security guarantees are not our explicit goal here, but r= ather a tangential goal to securing MLS use cases to the fullest possible ex= tent. That said, as noted by Jon Millican, any run-of-the-mill secure messag= ing application today, be it WhatsApp, Signal, iMessage, Facebook Messenger,= Google Allo, Viber, Wire, or Threema shows an obvious preference for epheme= rality and resistance to scenarios where the mobile phone, an increasingly d= isposable device, gets lost, stolen or traded away. >=20 > A5. As someone who's been involved in secure messaging for some time, I c= an say that it's by no coincidence that Signal was designed to focus so stro= ngly on both forward and future secrecy. The designers clearly went to great= length to keep these properties, and, in implementation, modulate their res= ilience against an unreliable (choppy, weak) network by keeping a certain nu= mber of pre-key hash chains locally. The more hash chains are kept, the more= out-of-order messages are tolerated by the wider the post-compromise window= . To my knowledge, WhatsApp keeps a larger local set of hash chains than, sa= y, Signal or Cryptocat, in order to account for its larger user base who may= have a smaller tolerance for failure. As a matter of fact, Signal as an app= lication evolved away from using pure OTR into designing and using the Signa= l protocol largely in order to improve upon forward secrecy specifically, ad= opting an asynchronous forward-secure AKE and a ratcheting scheme that handl= es two-party key contributivity much more quickly than OTR. >=20 > A6. I think it's doubly more important to consider adopting EKR's suggesti= on, discussed in (A3), to its fullest possible extent because of the negativ= e impact that accommodating against forward secrecy may have towards enablin= g downgrade attacks that chip away at forward secrecy. Once this is ingraine= d into the protocol, we may end up having to give an active attacker much st= ronger grip over when, and even if, forward secrecy ever kicks in. >=20 > Some responses to specific claims made by Phillip Hallam-Baker: >=20 > PHB Statement 1: "Alice works in a team with Bob and Carol. At some point D= oug joins the team. At that point, Doug needs access to all documents and di= scussions related to the project." >=20 > Response 1: Especially given that this seems to potentially require expand= ing the MLS problem space to document access, it is definitely best to follo= w EKR's recommendation, as mentioned above in (A3). Not only does this provi= de appropriate document access irrelevant of forward secrecy guarantees of M= LS, but it also segregates key retention to involve only documents that meri= t such retention, and from a software engineering standpoint is likely the m= ost elegant solution anyway. >=20 > PHB Statement 2: "If Alice creates a message for Bob using only her knowle= dge of Bob's public key then it is not going to be PFS because a compromise o= f Bob's private key is a breach." >=20 > Response 2: The consequences of the secrecy of the very first message in= a Signal session, given a long-term identity compromise, are not as you des= cribe. That is because you would also need to compromise Bob's one-time pre-= key, which is erased after the AKE concludes. The consequences of both these= kinds of compromise are modeled and documented by Katriel's Signal paper, a= s well as a contemporary paper published by our team at INRIA. >=20 > PHB Statement 3: "In general, I like to see what the requirements are befo= re jumping to implementation." >=20 > Response 3: It is quite likely that any current implementation of MLS isn'= t very fruitful. Better to discuss more first, especially at the upcoming me= eting at IETF 101. >=20 > PHB Statement 4: "This is a different problem to TLS because we have more t= han two parties and it changes matters." >=20 > Response 4: The manifestation of the problem is what is different. Not the= problem itself. The problem is layer security. TLS had to implement forward= secrecy in order to have a meaningful answer to that problem. In messaging,= the problem of layer security is the same, but manifests itself in a differ= ent medium. Forward secrecy is in all likelihood still necessary to offer th= ose affected by this problem the level of security they require given a reas= onable threat model. >=20 > PHB Statement 5: "One of the things I only just realized is that PFS is no= t even a property of the protocol, it is a property of a key in the exchange= and not of the exchange itself." >=20 > Response 5: Either this statement is incorrect, or all peer-reviewed publi= cations that exist on secure messaging must be rewritten in order to formali= ze, model and prove forward secrecy on the level of the lifetime of a symmet= ric key rather than as a global property encompassing all messages of a prot= ocol. Of course, there are different methods in which to reason about the sa= me thing: you can see a finite field as a weird squiggly line or as a set of= numbers, etc. >=20 > PHB Statement 6: "Let us say that we want FS with respect to each of the k= eys of Alice, Bob, Carol and Doug but =E2=80=8Bthey don't all want to inject= fresh FS information at the exact same time. Let us say Alice has her key i= n a HSM while Bob is using a soft key, Alice is sitting in a SOC and Bob is a= field agent on Moscow Rules. Bob probably wants for FS their key every ten m= inutes. Alice might be good for a week." >=20 > Response 6: In a protocol such as, for example, Signal, such a discrepancy= can be managed by the participants without affecting the protocol's impleme= ntation logic in any way, further supporting EKR's suggestion described in (= A3) and touched upon previously in the response to PHB Statement 2. >=20 > References: > [0] https://www.microsoft.com/en-us/research/publication/stronger-security= -of-authenticated-key-exchange/ >=20 > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > Sent from office >=20 >> On Fri, Mar 2, 2018, at 3:51 PM, Eric Rescorla wrote: >>> On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland wrote:= >>>=20 >>>> On 1 March 2018 at 15:11, Russ Housley wrote: >>>> This is similar to the approach used in some email environments. The >>> email >>>> message is decrypted for reading, and then encrypted in a separate >>> archive >>>> key for storage. >>>=20 >>> Sure, but that explicitly means that messages within the archive can >>> no longer be authenticated, doesn't it? >>>=20 >>=20 >> Not if they are digitally signed, which is an explicit option in the >> current drafts. >>=20 >> -Ekr >>=20 >>=20 >>=20 >> That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For >>> all its faults, that is providing a secure archive that the enterprise >>> has access to via an offline key escrow. >>>=20 >>> If I'm wrong here please don't hesitate to correct me. >>>=20 >>> Dave. >>>=20 >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls From nobody Fri Mar 2 18:09:30 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FE312708C for ; Fri, 2 Mar 2018 18:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzlAle6SweOm for ; Fri, 2 Mar 2018 18:09:28 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4A7127078 for ; Fri, 2 Mar 2018 18:09:28 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id b8so8404751oib.11 for ; Fri, 02 Mar 2018 18:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RhhMnnEkP0TZOjpFJT/vBdpBInhWONVSDHrVWKJyq94=; b=M8YBXfkiSZbzIs4XOOKPW4b3LHKLzKf21rwi7N0FyZ59cjW+FGaXWg5fM7iOBYchYW WKjonMIZNZDa+pQ1Sgasj2l+QO1SU6uqA4rY/S1y4cUXqd93+jviaq4kt+N6kmluZB4q 5zQNJ7goYHKlC89wH4DYFBkVFTU3DmmcRL3BMQWiCttsElRwF9IrT11ibmWQs1iGWZ8L zCIOpHiuPwlkRmhakUR25pt6AlXJN6WZmewGXnIkXbczli0OXODmHs9uOeXqBT09Xs+T xNbBnA39OEVXuUaYCdDVqdBe1j31dPXsqXtPiqwNW5mGTqbeXHwtiB+e/ilNlE5Jr8lw J+1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RhhMnnEkP0TZOjpFJT/vBdpBInhWONVSDHrVWKJyq94=; b=DmkPaCM8kOYEoe8STahVit6I5iaHEWoND+3XqV43x7yPl7ClSXa3WJd0C2/xHnaHwH fJ2oMgv2hCAA1PCOmYOR9c3uHLPd63QWQ2Y3RJSex1NQFCMPIq0CHO6IDrxW1loRRBDn CccUGfptIitbq8n0qL8D1aEfFhT/EOAPzsj1H4eFtjNMF6axe5mlV1YmJ0s6k1OeYH9V cCeFWLAuu7XLrnKXDTZs3lUOPF+w/Cbc6copCTpgxfeLQBRJEVcpiM/7co29uFzeocC8 ckvrW74Y6X9Cpg1qFvUnbIyiehnHZNP/xLmsytIdeTguBy25RsaBGQP7x+/eaoBlLA2b Gb7A== X-Gm-Message-State: APf1xPC0bporSyNGeyrl+nPISaIHfGWUS9Ez7VpQga7EDR+NPu7RFgB1 r5M82mUn++YDwP+2MUAZNK+AnQj0BjUDpaN3SHpMWA== X-Google-Smtp-Source: AG47ELtittLOHBJPys3iB1ow7wM8hCT1PLq4JET2A9HCeeOXPw/Y8p0QykkvR3zCeUearZWoQ2Mnn9lNxt2BYzwTfT8= X-Received: by 10.202.206.71 with SMTP id e68mr5182208oig.34.1520042967186; Fri, 02 Mar 2018 18:09:27 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.5.5 with HTTP; Fri, 2 Mar 2018 18:09:26 -0800 (PST) In-Reply-To: <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> References: <4D5030D8-E144-45E9-AB27-1B6E64A3C5F7@vigilsec.com> <1520014499.331302.1289437112.339C1876@webmail.messagingengine.com> From: Phillip Hallam-Baker Date: Fri, 2 Mar 2018 21:09:26 -0500 X-Google-Sender-Auth: riag38F1B82lj5SsXe9eSiOvvHk Message-ID: To: Nadim Kobeissi Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113cdb041a42e605667895e0" Archived-At: Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2018 02:09:30 -0000 --001a113cdb041a42e605667895e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 2, 2018 at 1:14 PM, Nadim Kobeissi wrote: > > Some responses to specific claims made by Phillip Hallam-Baker: > > PHB Statement 1: "Alice works in a team with Bob and Carol. At some point > Doug joins the team. At that point, Doug needs access to all documents an= d > discussions related to the project." > > Response 1: Especially given that this seems to potentially require > expanding the MLS problem space to document access, it is definitely best > to follow EKR's recommendation, as mentioned above in (A3). Not only does > this provide appropriate document access irrelevant of forward secrecy > guarantees of MLS, but it also segregates key retention to involve only > documents that merit such retention, and from a software engineering > standpoint is likely the most elegant solution anyway. > =E2=80=8B=E2=80=8B =E2=80=8BMy point is that discussions, i.e. the application for which we mi= ght want to use MLS very often have precisely the same security requirements as stored documents for which it is understood FS is not=E2=80=8B a requiremen= t. > PHB Statement 2: "If Alice creates a message for Bob using only her > knowledge of Bob's public key then it is not going to be PFS because a > compromise of Bob's private key is a breach." > > Response 2: The consequences of the secrecy of the very first message i= n > a Signal session, given a long-term identity compromise, are not as you > describe. That is because you would also need to compromise Bob's one-tim= e > pre-key, > =E2=80=8B=E2=80=8B > =E2=80=8BWhich has just taken you outside the scope of my statement. This i= s exactly the point I am making. I can add FS to a protocol really easily, just mix in another one time key. =E2=80=8BWhen I say 'only her knowledge o= f Bob's public key' that is what I mean, not 'only her knowledge of Bob's public key plus this other stuff'. =E2=80=8BSo the way to avoid FS in the case that it is undesirable is to no= t mix in the key in the first place. That is, FS is a security enhancement of a non FS-protocol, not something we design in and then take away.=E2=80=8B PHB Statement 3: "In general, I like to see what the requirements are > before jumping to implementation." > > Response 3: It is quite likely that any current implementation of MLS > isn't very fruitful. Better to discuss more first, especially at the > upcoming meeting at IETF 101. > =E2=80=8BI agree on that. And I find that quite often it is necessary to bu= ild something to work out what it is we really want to build.=E2=80=8B > PHB Statement 4: "This is a different problem to TLS because we have more > than two parties and it changes matters." > > Response 4: The manifestation of the problem is what is different. Not th= e > problem itself. The problem is layer security. TLS had to implement forwa= rd > secrecy in order to have a meaningful answer to that problem. In messagin= g, > the problem of layer security is the same, but manifests itself in a > different medium. Forward secrecy is in all likelihood still necessary to > offer those affected by this problem the level of security they require > given a reasonable threat model. > =E2=80=8BI agree. I think that the nature of forward secrecy is different a= s well. I can design a protocol that is FS to the keys of Alice and Bob but not Carol. I can also FS different keys at different times. =E2=80=8B > PHB Statement 5: "One of the things I only just realized is that PFS is > not even a property of the protocol, it is a property of a key in the > exchange and not of the exchange itself." > > Response 5: Either this statement is incorrect, or all peer-reviewed > publications that exist on secure messaging must be rewritten in order to > formalize, model and prove forward secrecy on the level of the lifetime o= f > a symmetric key rather than as a global property encompassing all message= s > of a protocol. Of course, there are different methods in which to reason > about the same thing: you can see a finite field as a weird squiggly line > or as a set of numbers, etc. > =E2=80=8BWell only the parts that address multi party protocols and I find = the literature is often barking up the wrong tree where requirements are concerned.=E2=80=8B > PHB Statement 6: "Let us say that we want FS with respect to each of the > keys of Alice, Bob, Carol and Doug but =E2=80=8Bthey don't all want to in= ject fresh > FS information at the exact same time. Let us say Alice has her key in a > HSM while Bob is using a soft key, Alice is sitting in a SOC and Bob is a > field agent on Moscow Rules. Bob probably wants for FS their key every te= n > minutes. Alice might be good for a week." > > Response 6: In a protocol such as, for example, Signal, such a discrepanc= y > can be managed by the participants without affecting the protocol's > implementation logic in any way, further supporting EKR's suggestion > described in (A3) and touched upon previously in the response to PHB > Statement 2. > =E2=80=8BQuite, and maybe there is an approach in which we use one set of k= eys to do a key agreement for authentication purposes and a second set of keys for a FS mix-in.=E2=80=8B --001a113cdb041a42e605667895e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Ma= r 2, 2018 at 1:14 PM, Nadim Kobeissi <nadim@symbolic.software>= ; wrote:

Some responses to specific claims made by Phillip Hallam-Baker:

PHB Statement 1: "Alice works in a team with Bob and Carol. At some po= int Doug joins the team. At that point, Doug needs access to all documents = and discussions related to the project."

Response 1: Especially given that this seems to potentially require expandi= ng the MLS problem space to document access, it is definitely best to follo= w EKR's recommendation, as mentioned above in (A3). Not only does this = provide appropriate document access irrelevant of forward secrecy guarantee= s of MLS, but it also segregates key retention to involve only documents th= at merit such retention, and from a software engineering standpoint is like= ly the most elegant solution anyway.
=E2=80=8B=E2=80=8B
=E2=80=8BMy point is t= hat discussions, i.e. the application for which we might want to use MLS ve= ry often have precisely the same security requirements as stored documents = for which it is understood FS is not=E2=80=8B a requirement.

=C2=A0
PHB Statement 2: "If Alice creates a message for Bob using only her kn= owledge of Bob's public key then it is not going to be PFS because a co= mpromise of Bob's private key is a breach."

Response 2:=C2=A0 =C2=A0The consequences of the secrecy of the very first m= essage in a Signal session, given a long-term identity compromise, are not = as you describe. That is because you would also need to compromise Bob'= s one-time pre-key,
=E2=80=8B=E2=80=8B

=E2=80=8BWhich has just= taken you outside the scope of my statement. This is exactly the point I a= m making. I can add FS to a protocol really easily, just mix in another one= time key. =E2=80=8BWhen I say 'only her know= ledge of Bob's public key' that is what I mean, not 'only her knowledge of Bob's public key plus this other = stuff'.

=E2=80=8BSo the way to avoid FS in the case that = it is undesirable is to not mix in the key in the first place. That is, FS = is a security enhancement of a non FS-protocol, not something we design in = and then take away.=E2=80=8B

PHB Statement= 3: "In general, I like to see what the requirements are before jumpin= g to implementation."

Response 3: It is quite likely that any current implementation of MLS isn&#= 39;t very fruitful. Better to discuss more first, especially at the upcomin= g meeting at IETF 101.

=E2=80=8BI agree on that. And I find= that quite often it is necessary to build something to work out what it is= we really want to build.=E2=80=8B


=C2= =A0
PHB Statement 4: "This is a different problem to TLS because we have m= ore than two parties and it changes matters."

Response 4: The manifestation of the problem is what is different. Not the = problem itself. The problem is layer security. TLS had to implement forward= secrecy in order to have a meaningful answer to that problem. In messaging= , the problem of layer security is the same, but manifests itself in a diff= erent medium. Forward secrecy is in all likelihood still necessary to offer= those affected by this problem the level of security they require given a = reasonable threat model.

=E2=80=8BI agree. I think that the= nature of forward secrecy is different as well. I can design a protocol th= at is FS to the keys of Alice and Bob but not Carol. I can also FS differen= t keys at different times. =E2=80=8B


=C2= =A0
PHB Statement 5: "One of the things I only just realized is that PFS i= s not even a property of the protocol, it is a property of a key in the exc= hange and not of the exchange itself."

Response 5: Either this statement is incorrect, or all peer-reviewed public= ations that exist on secure messaging must be rewritten in order to formali= ze, model and prove forward secrecy on the level of the lifetime of a symme= tric key rather than as a global property encompassing all messages of a pr= otocol. Of course, there are different methods in which to reason about the= same thing: you can see a finite field as a weird squiggly line or as a se= t of numbers, etc.

=E2=80=8BWell only the parts that addres= s multi party protocols and I find the literature is often barking up the w= rong tree where requirements are concerned.=E2=80=8B

=C2=A0
PHB Statement 6: "Let us say that we want FS with respect to each of t= he keys of Alice, Bob, Carol and Doug but =E2=80=8Bthey don't all want = to inject fresh FS information at the exact same time. Let us say Alice has= her key in a HSM while Bob is using a soft key, Alice is sitting in a SOC = and Bob is a field agent on Moscow Rules. Bob probably wants for FS their k= ey every ten minutes. Alice might be good for a week."

Response 6: In a protocol such as, for example, Signal, such a discrepancy = can be managed by the participants without affecting the protocol's imp= lementation logic in any way, further supporting EKR's suggestion descr= ibed in (A3) and touched upon previously in the response to PHB Statement 2= .

=E2=80=8BQuite, and maybe there is an approach in which w= e use one set of keys to do a key agreement for authentication purposes and= a second set of keys for a FS mix-in.=E2=80=8B

=C2=A0<= /div>
--001a113cdb041a42e605667895e0-- From nobody Wed Mar 7 19:42:25 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6552126BF7 for ; Wed, 7 Mar 2018 19:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtS_e1rMfk9Q for ; Wed, 7 Mar 2018 19:42:22 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561D71271FD for ; Wed, 7 Mar 2018 19:42:22 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id s188so5346843qkb.2 for ; Wed, 07 Mar 2018 19:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ALyHtrVeLG3J4HzHbD5h0vEPI76cgk00yZ9yskYiI5E=; b=Bx5IMl3nmrWRsum27RX1RTKyqdaSKRNztAZMRSXmgsE3jvTEvLgK+Auw3cvvvL2ezf PD+EC6g4Bg58GnaYg+QQ6NQ06FBBuvOMbhh1QzyGclhpFQmEH4DvZQbCKSpeXvBfwBnF e4a2eErtSaoHdwtGjbrP5tbRyDzyG7tfD7KfM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ALyHtrVeLG3J4HzHbD5h0vEPI76cgk00yZ9yskYiI5E=; b=UexS1idBU18G0jno2Od8klG6/a6MlZWpYclQw18inNPQwLrVg2jrO/fQNz4y0TStyl bFDqkx9wsj0x/kNd2hVbNOcAlYelSMZc+t52kbetEVBS9gGPD7dnVha2bUChm0Gq856h 4kkRn1rfYcgkrLR/iPi3Cofkh4KtmaJE3DGRFIFUAUDt1CAlAZxN41WegCpdRZWHaaxg XvCWDmQwdKMzUnXhVaa7llrWdg9+OmGixq/YWBzDn1fqDASnmfZvZ9mgXGz2MLONIXTJ zOIwUlhJyjQluU744yJ2LGMloe8hzqWgAa6cyyKJB4sAo7gTrBxR6geHu6Qm9SOyQ96j P08w== X-Gm-Message-State: AElRT7EfJi2GIM2DqjnWWmwzwS2+bVHsFbDYqHTGvowdKObhJ4rGDH1x HyjM66sNNlUL3iGTjLMVhsKn+MsbPac= X-Google-Smtp-Source: AG47ELuOu6+6xMieylxdmIl2WeGL3/2QgXOmHtJCIsQEtHCgIjoVhLM71T/maNdT6Y9WPBq1WLt2pw== X-Received: by 10.55.25.150 with SMTP id 22mr36839061qkz.183.1520480541309; Wed, 07 Mar 2018 19:42:21 -0800 (PST) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id i11sm13870070qtc.30.2018.03.07.19.42.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Mar 2018 19:42:20 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Wed, 7 Mar 2018 22:42:19 -0500 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [MLS] MLS@IETF101 Draft Agenda Posted X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 03:42:24 -0000 Here=E2=80=99s a link to the draft agenda for the MLS session @ IETF101: https://datatracker.ietf.org/meeting/101/materials/agenda-101-mls spt= From nobody Tue Mar 13 08:58:19 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78A9127241 for ; Tue, 13 Mar 2018 08:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, 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 PXkhN0VI93xK for ; Tue, 13 Mar 2018 08:58:03 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 944AD126DC2 for ; Tue, 13 Mar 2018 08:57:39 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id l8so281123wrg.5 for ; Tue, 13 Mar 2018 08:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kr+Vmv7cCYWL5xYo0bqHxHeb9zCSxj4WIDBNm4X5JS0=; b=BWI2ji0Af9TLAg6T25xrv7C35BHUn4Lkz1frSeDcCKqnIm7lTrOtbtJsd6EHS9auis DFHGPigSJ+xqZtGF42myWDJrFkqSa+pREnQ7dCfbizDi5oSPPusrFcpakMXveJQIVCwi U5uGM8jWenowg0pZtaBGJpaqTZlrqLaR44rX8tvh+18aH4n7ENNFnIyzKdUoEMWkDgJF HsaCV0igOBAXcYxJyVheDiMk/DT4nxyrC1i1H3TeKZoffy/wMLHSofiYVGmGr/1IDno6 rWMG/uqHU+lUaWRLCeTu7q8IZU+lZFTdMMeteLH8TWGsU+NgeOIDBiFc7TJKZgSJah1i X+Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kr+Vmv7cCYWL5xYo0bqHxHeb9zCSxj4WIDBNm4X5JS0=; b=FV5ChuUE4lThdHPfftnh1jSFfs9cGXdiS54/OgwsO24RHOPLEP12c+w/OIuqp+ImQn YonwzpfM0J0nY+m6ccQST/Bkq8CQbXHLi0p9UpleeSQX12O8Hr99oVnW5KSthy9QsIYj 2WUQW8tkEx4htBsbKqlPfuJR0qjdGbPX65/e3ICsx+5UMllX/AgrRudb5jf5lFC/9t7N Km9JZs7weVb5da7/IOAbrJplV4h3vGbo9ZUqmn+y2zywEBf1ZOClfLbHZf5X1ASxqBYe Xt+LKNs+fi1DTderzO+QBiEt0PNUEnG8Sr2w25NxAIbamgFnAir67+Fd68iZBBLqXhDz aoEA== X-Gm-Message-State: AElRT7GVevUhevgt+BMxnp34fFL1Dunw26Qbpv7PQQ2VmFj5Y2yta9KM mgQzvZCqYZTaLS/CIizviFJ+mzUJz4Pc/ClOI5CSu4fz0ws= X-Google-Smtp-Source: AG47ELvLvLOj48Xxg563YmysOkJUr50DfKgc0muiPgn4P4OVEWw+h5wtbp6TIM9tsnFOqm20Yzw++qjq0yjbePyGOM8= X-Received: by 10.223.171.167 with SMTP id s36mr1040554wrc.52.1520956657919; Tue, 13 Mar 2018 08:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Tue, 13 Mar 2018 08:57:37 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 13 Mar 2018 11:57:37 -0400 Message-ID: To: Simon Friedberger Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113b37b6507e8c05674d5121" Archived-At: Subject: Re: [MLS] [Mls] Comments on Charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 15:58:18 -0000 --001a113b37b6507e8c05674d5121 Content-Type: text/plain; charset="UTF-8" Hey Simon, Thanks for the comments, sorry for the delay. On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger wrote: > 1. I think key transparency should be mentioned. Key distribution is a > huge semi-solved problem and leaving it out is not really an option. It > seriously degrades security for the average user who does not validate > keys. > Obviously, I agree that authentication is very important, but from what I've heard talking to people, there's not energy to do KT right now. What we can do now is make sure there's a slot to put a credential in, so that we can leverage things like PKI that provide some benefit over manual key comparison, and later on we can recharter to work on KT if there's interest. To clarify this, I added the following para: """ While authentication is a key goal of this working group, it is not the objective of this working group to new authentication technologies. Rather, the security protocol developed by this group will provide a way to leverage existing authentication technologies to associate identities with keys used in the protocol, just as TLS does with X.509. """ > 2. Federation (for example like in XMPP, where many people run their own > servers just like for e-mail) probably doesn't require anything specific > but it should be discussed to make sure that it works. It would also be > good to take this into account when discussing authentication and key > transparency to make sure it is clear which guarantees hold for people > on other servers. I think it doesn't necessarily have to be in the > charter but should be in any final proposal. > I think the critical thing to test / validate is that we have interoperability at the level of the specification of the protocol. Just like BoringSSL and NSS interoperate at the level of TLS, but don't assure interoperability of HTTP running over them, we should be aiming for a security protocol that's interoperable between independent implementations, but not worried about interoperability of the rest of the stack. I did make the following tweak to the charter language, though: "to enable interoperability" -> "to enable interoperability / federation" > > > Best Regards, > > Simon > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --001a113b37b6507e8c05674d5121 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Simon,

Thanks for the co= mments, sorry for the delay.

<= div class=3D"gmail_quote">On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger= <simon.cfrg@a-oben.org> wrote:
1. I think key transparency should be mentione= d. Key distribution is a
huge semi-solved problem and leaving it out is not really an option. It
seriously degrades security for the average user who does not validate keys= .

Obviously, I agree that authenticatio= n is very important, but from what I've heard talking to people, there&= #39;s not energy to do KT right now.=C2=A0 What we can do now is make sure = there's a slot to put a credential in, so that we can leverage things l= ike PKI that provide some benefit over manual key comparison, and later on = we can recharter to work on KT if there's interest.

To clarify this, I added the following para:

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

= =C2=A0
2. Federation (for example like in XMPP, where many people run their own servers just like for e-mail) probably doesn't require anything specifi= c
but it should be discussed to make sure that it works. It would also be
good to take this into account when discussing authentication and key
transparency to make sure it is clear which guarantees hold for people
on other servers. I think it doesn't necessarily have to be in the
charter but should be in any final proposal.

I think the critical thing to test / validate is that we have interop= erability at the level of the specification of the protocol.=C2=A0 Just lik= e BoringSSL and NSS interoperate at the level of TLS, but don't assure = interoperability of HTTP running over them, we should be aiming for a secur= ity protocol that's interoperable between independent implementations, = but not worried about interoperability of the rest of the stack.
=
I did make the following tweak to the charter language, thou= gh:

"to enable interoperability" -> &= quot;to enable interoperability / federation"

=

=C2=A0


Best Regards,

Simon

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

--001a113b37b6507e8c05674d5121-- From nobody Tue Mar 13 08:59:17 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C090F12DA6D for ; Tue, 13 Mar 2018 08:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, 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 GANf0D7T0Nln for ; Tue, 13 Mar 2018 08:58:54 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8427A12D95B for ; Tue, 13 Mar 2018 08:58:53 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id o8so332334wra.1 for ; Tue, 13 Mar 2018 08:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rWr19/RX3aHH4Q+373z676lyhFR7f4LgDFotZy+9d+M=; b=EuuR5OshkEj/ikvAM1KHis5H+GYC/c/ADB9qfrBSfQCYmIvGSXRe/w97f9JuI2Z1/u J3RYfYTty+7afbqk8U0n/7Qk8pZlGNF8lIZqbiHHqx7k32dN1sB1N+tBR8jCMJH3Ni6f AhKvOBHQwsl0SHSjZN2BJwo+OH/4egP+d2gM3DtQ/g369XoLzFt/GdXlVUE9lz/H3k2r 0q1ZB2VMMUhRoIOnrRaByn2dq70lufu7alNIj7XVMYeRm3MhQ/nOoE3lqUdyzeQqx6A+ Hbe9TcZqwYqYU+3oc0gRB5N1FsVWzxX7zYTHGklS6sfBsVyETx5UtiXobDRXYtWgaBID MfpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rWr19/RX3aHH4Q+373z676lyhFR7f4LgDFotZy+9d+M=; b=MgyuEYae0QQEhXiO40ZMUY/6egty1V6LVwT+QQXs/4U/WigzKvIytTwI0vmFFQUKgV 3w3PX7UzZYRJg+8LoquYQk5w+w2QJdn+eCYcLbtFa0hzyDj2XSeVFfCJOQGOXer8ca/S 4ngI2afybWtp1N9m0h3ZpW333fCUlupmp3vsas+irSytfxJnXeYG15mOBypCpq0EsTVe tVyeCTePwS1xoFTAZuk0TdI9QA/WzZ/Vs2Ob/pg4doTeh6UkY6OnEbJDVyEdeUjlBt7H jh5SPC4xGjQOeX+L1mKmnOgsDYeEK3Rk+yw2NmYdsUgq1EfO2S/2mO3op78bxq7eS9Ku n9JQ== X-Gm-Message-State: AElRT7GkQEb8cTDQmjJty37BqOZYZVHC09FHiB3V28v603CDgA3Ybg2u /40uUqhGp6c+0YR/URiqbY6PiFzNm9+XhPwSJ86JlAl0 X-Google-Smtp-Source: AG47ELu+KyF5Z8sVrNaPO4gaxuiALUoun4agdyhi5Q7osIm/9xKdzbontRFQ2iq3O5NPL5oc8yCoJvbQBP2DLjWAKR8= X-Received: by 10.28.153.133 with SMTP id b127mr1152693wme.105.1520956731389; Tue, 13 Mar 2018 08:58:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Tue, 13 Mar 2018 08:58:50 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 13 Mar 2018 11:58:50 -0400 Message-ID: To: mls@ietf.org Content-Type: multipart/alternative; boundary="001a114b2f36b18b8205674d559f" Archived-At: Subject: Re: [MLS] Draft charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2018 15:59:17 -0000 --001a114b2f36b18b8205674d559f Content-Type: text/plain; charset="UTF-8" Reminder: The MLS BoF is a little more than a week away, so please get any comments on the charter in ASAP! On Mon, Feb 5, 2018 at 1:20 PM, Richard Barnes wrote: > Hey all, > > In order to establish a working group, we need to have a charter that > describes what the WG is supposed to do. Agreeing on the charter will be > one of the major things to do at the BoF. To get ready for that, I've put > an initial draft (based on the BoF request text) in this Google Doc: > > https://docs.google.com/document/d/1OrvqnLsnVDQBN1fnlzkfBoS31vyQV > k5Zs-a-tz99ku4/edit?usp=sharing > > Feel free to suggest edits or put comments there, but if there's anything > that needs discussion, please reply in this thread instead. > > Thanks, > --Richard > > --001a114b2f36b18b8205674d559f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reminder: The MLS BoF is a little more than a week away, s= o please get any comments on the charter in ASAP!

On Mon, Feb 5, 2018 at 1:20 PM, R= ichard Barnes <rlb@ipv.sx> wrote:
Hey all,

In order to establ= ish a working group, we need to have a charter that describes what the WG i= s supposed to do.=C2=A0 Agreeing on the charter will be one of the major th= ings to do at the BoF.=C2=A0 To get ready for that, I've put an initial= draft (based on the BoF request text) in this Google Doc:


Feel free = to suggest edits or put comments there, but if there's anything that ne= eds discussion, please reply in this thread instead.

Thanks,
--Richard


--001a114b2f36b18b8205674d559f-- From nobody Fri Mar 16 06:06:17 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9B81241F3 for ; Fri, 16 Mar 2018 06:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYZ8OgbpzgN8 for ; Fri, 16 Mar 2018 06:06:10 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 1B78312706D for ; Fri, 16 Mar 2018 06:06:10 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id i14so4050956pgv.3 for ; Fri, 16 Mar 2018 06:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=23a917LJ5G6iVGpvIPPr59XzALgKSxw86yhOS3Hj1BE=; b=Mi1vXTyjQ9yjKs06pAh2wDVC5sGEA5Gih9Zy/RrH3yOzXFEI5zse75bGMa2WwXvxef wX3MojKu3t6o2QlmTAfh11nH7iBkS7EwBg5qHW+cbrZd5o+8v6dDZ/a6ykdQ6Sl4gNeD 59SDpTsbQH208OazlxVbxq92ulYr/+6khMAIA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=23a917LJ5G6iVGpvIPPr59XzALgKSxw86yhOS3Hj1BE=; b=qBC0GYetrDV2BjM43IEFGd29eZjpluPKfR15O5SO+gNH10dJSGA92/rxhPgLCRRfzi czxClosL1oWrWB2v5ebuTmg2WGjNH9TyTeXze4WRsmWAmQylj50gScOHi08MSB6fi6TC c6jAfvqtUjzw1mT9Zc+C9jxAlHcqSWkhldX24LkN03T0wHad0ihqfLL5skJtvcolk/Qg RUqqGI9iyEgJuuCmJxQ/qbGnTNUyU7sPkKDX5mtRbFVAU97dW4f20IvQTKQzgd1Ky7BO 78MsxsuTqstFXWc9AfBqyS+oQiX0zQaOFeckcgC2RXpKK0fz3ebwLLUSFC+vg4+CUIdn /eMw== X-Gm-Message-State: AElRT7Hu+kj7pbb+QqrcS4oEPoosSbrW/GRvmlFyn4e9IcULvreWdfvj NrhoOFxAZZwDZ+EUaHwYY4yBOlGuzuk= X-Google-Smtp-Source: AG47ELtzJVYYHr21w9iJVZyXrYqqYaKEBlV6imdAsTyjvPIc2ks+fNVIxUsDtMumXux6qTKuwRvSHA== X-Received: by 10.167.128.194 with SMTP id a2mr1567957pfn.186.1521205569219; Fri, 16 Mar 2018 06:06:09 -0700 (PDT) Received: from [5.5.33.98] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id v8sm14920293pff.38.2018.03.16.06.06.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 06:06:08 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <6C8F07FE-94D0-4E68-9E61-88FE543A0A6E@sn3rd.com> Date: Fri, 16 Mar 2018 13:06:02 +0000 To: mls@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [MLS] MLS@IETF101 Final Agenda Posted X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 13:06:16 -0000 Here=E2=80=99s a link to the agenda for the MLS session @ IETF101: https://datatracker.ietf.org/meeting/101/materials/agenda-101-mls spt= From nobody Sun Mar 18 08:35:43 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D912D886 for ; Sun, 18 Mar 2018 08:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy9r8PLbEfLG for ; Sun, 18 Mar 2018 08:35:40 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9654A12DA2C for ; Sun, 18 Mar 2018 08:35:37 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z184so15909690qkc.1 for ; Sun, 18 Mar 2018 08:35:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZrbhSJuE4wOguh66S/tmDUh3eVLi7ns8+wpQ1Sw8Umw=; b=Al6jMFOSnTUeItfcN5SaWJVh5M4IC8fVsMmZti5QXHPaWsD4itw2ZQC0SS7r5t+YQW pWTKxV1QDgblQSDYQ+IdqWdH11tHIH9frnsP1oxJmHoNmh8UN/gRz9dP4NbEqIpPTLfI zNgiQWIVTgaQKhvHrcGMG5WIe9jGi4QQWbBeZyqmbGNpjS7ZD5KTPoOdtH+cee4JYT6U 5Ca9QqXAqsI9cfWiflckd+xIgkwd+l2hXEhjfv4/BHgjLNcD8r08VLs99H+RjuooehdK BKIMYHMvt8584J4XLFOtRcwalBNsVrv+UpyH+V+4ZtQt+HW11dFBWPvo0t8jZMxd1i4C FjGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZrbhSJuE4wOguh66S/tmDUh3eVLi7ns8+wpQ1Sw8Umw=; b=kbeDt+KtNfffpWEh3hBewNF6D0LKiFcwy/+ZcB+G52jnGMt/OZbG29wJ0upOfyeLfS 5Ez6zQt1U7E9hAY7BlAL4jwWU4S9QN395+qyktfMlnujGo8HqbNrtENWl+WaWHpWjOuV AhO2MDINkb8UbpEdw8ZdLfiaMlgk1jKfOD7AytiGrHo4fzjNSzSOpDjitA2gla1ZJuJa sNevIkzRwv7D5ek5zn0tLI7BgOlugA1Q3UXSNlJHUaNFezElWuVjBLres9nFxrVrIpGa 6R5VsZAkHCOUdhvs2UPhl0U5Dn8uYIxcWWdP+XkBpbMBjXNQYdCAbb/P3YfrpgYu1ErX Oo/w== X-Gm-Message-State: AElRT7FriwYp6cEYQe1KrjR+xxNefqAHhHKB86dRBzSB9fiUWkg33aps JwDYULNrD88PtNUf4C4AxJhKAT1j39E+LTFvfFriUG0P X-Google-Smtp-Source: AG47ELtVJlj4iwMNv39N2+jXmzam0hP9pdRA6FPep3dqxYJFZSG4vRXW2Zr1zhP9dQyEOMVOrLjFJLNFKF+1y1u6y0o= X-Received: by 10.55.198.153 with SMTP id s25mr12597396qkl.221.1521387336640; Sun, 18 Mar 2018 08:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.234 with HTTP; Sun, 18 Mar 2018 08:34:56 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 18 Mar 2018 15:34:56 +0000 Message-ID: To: Richard Barnes Cc: Simon Friedberger , mls@ietf.org Content-Type: multipart/alternative; boundary="001a11430b28c441520567b19740" Archived-At: Subject: Re: [MLS] [Mls] Comments on Charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 15:35:42 -0000 --001a11430b28c441520567b19740 Content-Type: text/plain; charset="UTF-8" IMO the charter should just say we're adopting these documents as a starting point, with an explicit disclaimer about how everything needs consensus (the QUIC charter has some good text here). They're in a pretty mature state and reflect what there's already been enthusiasm for. -Ekr On Tue, Mar 13, 2018 at 3:57 PM, Richard Barnes wrote: > Hey Simon, > > Thanks for the comments, sorry for the delay. > > On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger > wrote: > >> 1. I think key transparency should be mentioned. Key distribution is a >> huge semi-solved problem and leaving it out is not really an option. It >> seriously degrades security for the average user who does not validate >> keys. >> > > Obviously, I agree that authentication is very important, but from what > I've heard talking to people, there's not energy to do KT right now. What > we can do now is make sure there's a slot to put a credential in, so that > we can leverage things like PKI that provide some benefit over manual key > comparison, and later on we can recharter to work on KT if there's interest. > > To clarify this, I added the following para: > > """ > While authentication is a key goal of this working group, it is not the > objective of this working group to new authentication technologies. > Rather, the security protocol developed by this group will provide a way to > leverage existing authentication technologies to associate identities with > keys used in the protocol, just as TLS does with X.509. > """ > > > >> 2. Federation (for example like in XMPP, where many people run their own >> servers just like for e-mail) probably doesn't require anything specific >> but it should be discussed to make sure that it works. It would also be >> good to take this into account when discussing authentication and key >> transparency to make sure it is clear which guarantees hold for people >> on other servers. I think it doesn't necessarily have to be in the >> charter but should be in any final proposal. >> > > I think the critical thing to test / validate is that we have > interoperability at the level of the specification of the protocol. Just > like BoringSSL and NSS interoperate at the level of TLS, but don't assure > interoperability of HTTP running over them, we should be aiming for a > security protocol that's interoperable between independent implementations, > but not worried about interoperability of the rest of the stack. > > I did make the following tweak to the charter language, though: > > "to enable interoperability" -> "to enable interoperability / federation" > > > > >> >> >> Best Regards, >> >> Simon >> >> _______________________________________________ >> 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 > > --001a11430b28c441520567b19740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IMO the charter should just say we're adopting these d= ocuments as a starting point, with an explicit disclaimer about how everyth= ing needs consensus (the QUIC charter has some good text here). They're= in a pretty mature state and reflect what there's already been enthusi= asm for.

-Ekr


On Tue, Mar 13, 2018 at 3:57 PM, = Richard Barnes <rlb@ipv.sx> wrote:
Hey Simon,

Thanks for th= e comments, sorry for the delay.
<= br>
On Tue, Feb 6, 2018 at 7:11 = AM, Simon Friedberger <simon.cfrg@a-oben.org> wrote:
=
1. I think key transparen= cy should be mentioned. Key distribution is a
huge semi-solved problem and leaving it out is not really an option. It
seriously degrades security for the average user who does not validate keys= .

Obviously, I agree that authen= tication is very important, but from what I've heard talking to people,= there's not energy to do KT right now.=C2=A0 What we can do now is mak= e sure there's a slot to put a credential in, so that we can leverage t= hings like PKI that provide some benefit over manual key comparison, and la= ter on we can recharter to work on KT if there's interest.
To clarify this, I added the following para:
"""
While authentication is a key goal= of this working group, it is not the objective of this working group to ne= w authentication technologies.=C2=A0 Rather, the security protocol develope= d by this group will provide a way to leverage existing authentication tech= nologies to associate identities with keys used in the protocol, just as TL= S does with X.509.
"""

=C2=A0
2. Federation (for example like in XMPP, where many people run their own servers just like for e-mail) probably doesn't require anything specifi= c
but it should be discussed to make sure that it works. It would also be
good to take this into account when discussing authentication and key
transparency to make sure it is clear which guarantees hold for people
on other servers. I think it doesn't necessarily have to be in the
charter but should be in any final proposal.

I think the critical thing to test / validate is that we have = interoperability at the level of the specification of the protocol.=C2=A0 J= ust like BoringSSL and NSS interoperate at the level of TLS, but don't = assure interoperability of HTTP running over them, we should be aiming for = a security protocol that's interoperable between independent implementa= tions, but not worried about interoperability of the rest of the stack.

I did make the following tweak to the charter languag= e, though:

"to enable interoperability" = -> "to enable interoperability / federation"


=C2=A0


Best Regards,

Simon

_______________________________________________
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


--001a11430b28c441520567b19740-- From nobody Sun Mar 18 08:45:25 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77398127AD4 for ; Sun, 18 Mar 2018 08:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 cPPwfMqKXdIJ for ; Sun, 18 Mar 2018 08:45:22 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB09F12711B for ; Sun, 18 Mar 2018 08:45:21 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id u46so2129580wrc.11 for ; Sun, 18 Mar 2018 08:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jci/Z3vrkRdo/3jUSyX58oq2st1ubzBeEx+UEJsV4MA=; b=sc2nNHil6ZLefrGkXXtbo0IFgRPihe0xbd7Ycyqhr8xlALOdaynx7BFC0wGTFuMTV3 tVq2+zoR+ZEQ8dUHGmMzKFtR2DKr2rYVL9QJZwH9uLCU/fVyNZ3V+TsrCDETRSRnbBWp FsYQ0h1V41YLSQt+RUF4dECAfs2ozo67VHpM3R4f3XdPvJqWYpp78qhTCDUQoLeDv3dF OytmLvVGuET31Vmf9V8JyuMpblJ4ztrzu6cTVHghTC+4f5Qn/KbRPhMh+67MlWEjpw0h V6RxGdvAS6ZEGXo4dTKgexbYYxdvq75eBGOHlEHnhP6AwMi1xWVPGGVc+s5dJLzn7p2v 7t2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jci/Z3vrkRdo/3jUSyX58oq2st1ubzBeEx+UEJsV4MA=; b=MLMUo/zeUniuhlH5Wc/pI4YatgGurHc9h4fPFv2HP5F3sgEI5KWy8XrWVVkQOCgG44 oBjZgpXgGbSINnb6cz0DG06S+2QoJJbKAvlsfrq0TZ0Xy9keWrTXZiyx7AZIHaWqebGd +R1GlkIbwxHJJpvoNvFgroLqCOlotfLVuL0MWEj0Dycy7tcj5RzPzPRCFNFlq3BOHDwY JRc8d9QR5HjYGgl/A7HeXXDJJaa8e79RatsuEKrvxtypMRTZnhOOuuGQo87sphoAZz3Y Ibkz36CPHJA/0QK3SKowNtfZe1TE8l29micR4NiJ8UepD/hAN8gLeyTHAvEhlZyBbIIy ZJlA== X-Gm-Message-State: AElRT7H0v+iCPBBtS6UBTZyH5dYht0k1GyakMtW2bnniErM6/q1iXgsd Hx05P7pu3PaNnwonjEMJR4Go0QpWRjF5lz9D7r1Bag0Wrac= X-Google-Smtp-Source: AG47ELvA1HQUvlECEboGoEGbHu7h6Q5uJL3UTMIO2dvvmnga08zuHSe2gR2eRwoVIH2O8e/jFi4lLUtXwolrfmkClDE= X-Received: by 10.223.187.147 with SMTP id q19mr6518543wrg.150.1521387920256; Sun, 18 Mar 2018 08:45:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Sun, 18 Mar 2018 08:45:19 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Sun, 18 Mar 2018 15:45:19 +0000 Message-ID: To: Eric Rescorla Cc: Simon Friedberger , mls@ietf.org Content-Type: multipart/alternative; boundary="089e0820f2b88d89da0567b1bab6" Archived-At: Subject: Re: [MLS] [Mls] Comments on Charter X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 15:45:24 -0000 --089e0820f2b88d89da0567b1bab6 Content-Type: text/plain; charset="UTF-8" That sounds good to me. I've added the following text to the Google Doc (adapted from the QUIC charter): """ The specifications developed by this working group will be based on pre-standardization implementation and deployment experience, and generalizing the design described in: * draft-omara-mls-architecture * draft-barnes-mls-protocol Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified. """ On Sun, Mar 18, 2018 at 3:34 PM, Eric Rescorla wrote: > IMO the charter should just say we're adopting these documents as a > starting point, with an explicit disclaimer about how everything needs > consensus (the QUIC charter has some good text here). They're in a pretty > mature state and reflect what there's already been enthusiasm for. > > -Ekr > > > On Tue, Mar 13, 2018 at 3:57 PM, Richard Barnes wrote: > >> Hey Simon, >> >> Thanks for the comments, sorry for the delay. >> >> On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger >> wrote: >> >>> 1. I think key transparency should be mentioned. Key distribution is a >>> huge semi-solved problem and leaving it out is not really an option. It >>> seriously degrades security for the average user who does not validate >>> keys. >>> >> >> Obviously, I agree that authentication is very important, but from what >> I've heard talking to people, there's not energy to do KT right now. What >> we can do now is make sure there's a slot to put a credential in, so that >> we can leverage things like PKI that provide some benefit over manual key >> comparison, and later on we can recharter to work on KT if there's interest. >> >> To clarify this, I added the following para: >> >> """ >> While authentication is a key goal of this working group, it is not the >> objective of this working group to new authentication technologies. >> Rather, the security protocol developed by this group will provide a way to >> leverage existing authentication technologies to associate identities with >> keys used in the protocol, just as TLS does with X.509. >> """ >> >> >> >>> 2. Federation (for example like in XMPP, where many people run their own >>> servers just like for e-mail) probably doesn't require anything specific >>> but it should be discussed to make sure that it works. It would also be >>> good to take this into account when discussing authentication and key >>> transparency to make sure it is clear which guarantees hold for people >>> on other servers. I think it doesn't necessarily have to be in the >>> charter but should be in any final proposal. >>> >> >> I think the critical thing to test / validate is that we have >> interoperability at the level of the specification of the protocol. Just >> like BoringSSL and NSS interoperate at the level of TLS, but don't assure >> interoperability of HTTP running over them, we should be aiming for a >> security protocol that's interoperable between independent implementations, >> but not worried about interoperability of the rest of the stack. >> >> I did make the following tweak to the charter language, though: >> >> "to enable interoperability" -> "to enable interoperability / federation" >> >> >> >> >>> >>> >>> Best Regards, >>> >>> Simon >>> >>> _______________________________________________ >>> 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 >> >> > --089e0820f2b88d89da0567b1bab6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That sounds good to me.=C2=A0 I've added the foll= owing text to the Google Doc (adapted from the QUIC charter):
"""
The specifications developed by th= is working group will be based on pre-standardization implementation and de= ployment experience, and generalizing the design described in:

* draft-omara-mls-architecture
* draft-barnes-mls-proto= col

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


On Sun, Mar 18, 2018 at 3:34 PM, Er= ic Rescorla <ekr@rtfm.com> wrote:
IMO the charter should just say we're adopting thes= e documents as a starting point, with an explicit disclaimer about how ever= ything needs consensus (the QUIC charter has some good text here). They'= ;re in a pretty mature state and reflect what there's already been enth= usiasm for.

-Ekr


On Tue, Mar 13, 2018 at 3:57 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey Simo= n,

Thanks for the comments, sorry for the delay.

On Tue, Feb 6, 2018 at 7:11 AM, Simon Friedberger <<= a href=3D"mailto:simon.cfrg@a-oben.org" target=3D"_blank">simon.cfrg@a-oben= .org> wrote:
1. I think key transparency should be mentioned. Key distribution is a=
huge semi-solved problem and leaving it out is not really an option. It
seriously degrades security for the average user who does not validate keys= .

Obviously, I agree that authen= tication is very important, but from what I've heard talking to people,= there's not energy to do KT right now.=C2=A0 What we can do now is mak= e sure there's a slot to put a credential in, so that we can leverage t= hings like PKI that provide some benefit over manual key comparison, and la= ter on we can recharter to work on KT if there's interest.
To clarify this, I added the following para:
"""
While authentication is a key goal= of this working group, it is not the objective of this working group to ne= w authentication technologies.=C2=A0 Rather, the security protocol develope= d by this group will provide a way to leverage existing authentication tech= nologies to associate identities with keys used in the protocol, just as TL= S does with X.509.
"""
=C2=A0
2. Federation (for example like in XMPP, where many people run their own servers just like for e-mail) probably doesn't require anything specifi= c
but it should be discussed to make sure that it works. It would also be
good to take this into account when discussing authentication and key
transparency to make sure it is clear which guarantees hold for people
on other servers. I think it doesn't necessarily have to be in the
charter but should be in any final proposal.

I think the critical thing to test / validate is that we have = interoperability at the level of the specification of the protocol.=C2=A0 J= ust like BoringSSL and NSS interoperate at the level of TLS, but don't = assure interoperability of HTTP running over them, we should be aiming for = a security protocol that's interoperable between independent implementa= tions, but not worried about interoperability of the rest of the stack.

I did make the following tweak to the charter languag= e, though:

"to enable interoperability" = -> "to enable interoperability / federation"


=C2=A0


Best Regards,

Simon

_______________________________________________
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



--089e0820f2b88d89da0567b1bab6-- From nobody Fri Mar 23 06:28:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C260212D94F for ; Fri, 23 Mar 2018 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_YykMkNXs7C for ; Fri, 23 Mar 2018 06:28:44 -0700 (PDT) Received: from VirgilSecurity.com (mail.virgilsecurity.com [199.58.211.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E34212D953 for ; Fri, 23 Mar 2018 06:28:44 -0700 (PDT) Received: from BIGONE (unknown [176.226.240.214]) by VirgilSecurity.com (Postfix) with ESMTPSA id 32D441051530AF for ; Fri, 23 Mar 2018 09:28:41 -0400 (EDT) From: "Alexey Ermishkin" To: Date: Fri, 23 Mar 2018 18:28:39 +0500 Message-ID: <006201d3c2aa$dc9fded0$95df9c70$@virgilsecurity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdPCqsZCTIG6SJi1TZyDjbMudGiBbw== Content-Language: ru Archived-At: Subject: [MLS] Virgil Security would like to join the MLS development process X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 13:28:47 -0000 Hi, my name's Alex Ermishkin. I'm Chief Product Security Officer at Virgil Security, Inc. which focuses on delivering end-to-end encryption-based solutions to developers and businesses. We are the guys behind NoiseSocket protocol, a TLS alternative without certificates, which is now in active development together with the author of the Noise Protocol Framework (noiseprotocol.org) and the Signal protocol, Trevor Perrin. We would like to offer help in implementing MLS drafts along the way. We already have open source SDKs for 9 platforms (https://github.com/VirgilSecurity) and would like all of them to support MLS. Is it still possible to become a member of the working group? We could provide real world protocol implementations, test integrations, feedback from the real customers. Let us know if you'd be interested in talking. From nobody Fri Mar 23 07:02:01 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22415126CD8 for ; Fri, 23 Mar 2018 07:01:59 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=symbolic.software 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 MfoKpIR0lKiY for ; Fri, 23 Mar 2018 07:01:56 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3411243F6 for ; Fri, 23 Mar 2018 07:01:56 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id l12-v6so13330799otj.7 for ; Fri, 23 Mar 2018 07:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yaRYq9HJbGsGZngdhFNOKCOfPa6YUzDPt02akY2t2WE=; b=Db66M9uKr3/4veLEhdKIazkCAg5EMY65jT0hBWgFosDxxGXE2DsgHRt2UfkXOkwbZN l0HQGSG0W/pmHrNRFDTSnzqt5US15mCy0Q5itEs55wG4DljSl0b2fh3ZufFxAJRBwb4o 6m5xuOiVMf1BndUWRXEjIfXC4EQJ6/OCqbgY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yaRYq9HJbGsGZngdhFNOKCOfPa6YUzDPt02akY2t2WE=; b=hL/IVzWuLZdpmApqxXYLhigav+u9U570GFQhTsWFPg/zMTqa9PB5gEMugJQnL5Dw1s e5pUD3TXi3UcKPPJOjmWJgEFlsX6Y39xs0fic8o2vJ7qG6OJhAscfYCf2xap8EkYhrb8 pAgOVKQpCH/iF8fuJQ+OfB2JDgOXFtNTGtP3AaVLEC2E9Zu2uyPysKeQD3YZCwMS5lfr smgQyCxq8InoOy9a4W5jpEhZaVW/cM3E5FeIduZYJMHSg+nSF0+XpBID67btP/Hl+zLJ 0EnnIXXXPlK+v9fjCayJO4I+AI67uWDGJ+TwWafB79lTA6uQmJ4AsJYhsg/nWzYQijx7 iKRQ== X-Gm-Message-State: AElRT7ExBVC7Nb5KcqhwfMMc6GOgvdQsgqPM5Bn8hOOXHC8QIvtN/2Gz 5hJ+H9vhiDC08/E69PhUpn2jFp2lqQlm9AnBitSMjA== X-Google-Smtp-Source: AG47ELuh7/IDFoTyMZ024NVaieRmMpqeqed/4rUb4NwaVliUp331Ilsrbb4v/LEqRwJLsWZ3s4nhFhY16lWY0c5fEHI= X-Received: by 2002:a9d:5e16:: with SMTP id d22-v6mr19261012oti.107.1521813713750; Fri, 23 Mar 2018 07:01:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:5e16:0:0:0:0:0 with HTTP; Fri, 23 Mar 2018 07:01:53 -0700 (PDT) X-Originating-IP: [85.203.44.68] In-Reply-To: <006201d3c2aa$dc9fded0$95df9c70$@virgilsecurity.com> References: <006201d3c2aa$dc9fded0$95df9c70$@virgilsecurity.com> From: Nadim Kobeissi Date: Fri, 23 Mar 2018 14:01:53 +0000 Message-ID: To: Alexey Ermishkin Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2a1ad056814dd09" Archived-At: Subject: Re: [MLS] Virgil Security would like to join the MLS development process X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 14:01:59 -0000 --000000000000d2a1ad056814dd09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexey, I think it's possible for you to simply follow along the MLS development process, offering suggestions and feedback along the way, same as myself or anyone else. If you would like to develop implementations, test integration, etc. also, that is something you can do out of your own volition as the standard progresses and matures, without asking for permission or obtaining some kind of agreement with anyone. Then, you can share your work, progress and findings with the list, and everyone can provide feedback and learn from your work. Regards, Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office On Fri, Mar 23, 2018 at 1:28 PM, Alexey Ermishkin < scratch@virgilsecurity.com> wrote: > Hi, my name's Alex Ermishkin. > I'm Chief Product Security Officer at Virgil Security, Inc. which focuses > on > delivering end-to-end encryption-based solutions to developers and > businesses. > We are the guys behind NoiseSocket protocol, a TLS alternative without > certificates, which is now in active development together with the author > of > the Noise Protocol Framework (noiseprotocol.org) and the Signal protocol, > Trevor Perrin. > We would like to offer help in implementing MLS drafts along the way. We > already have open source SDKs for 9 platforms > (https://github.com/VirgilSecurity) and would like all of them to support > MLS. > Is it still possible to become a member of the working group? > We could provide real world protocol implementations, test integrations, > feedback from the real customers. > Let us know if you'd be interested in talking. > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000d2a1ad056814dd09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexey,
I think it's possib= le for you to simply follow along the MLS development process, offering sug= gestions and feedback along the way, same as myself or anyone else.

=
If you would like to develop implementations, test integration, etc. = also, that is something you can do out of your own volition as the standard= progresses and matures, without asking for permission or obtaining some ki= nd of agreement with anyone. Then, you can share your work, progress and fi= ndings with the list, and everyone can provide feedback and learn from your= work.

Regards,



Nadim Kobeissi
Symbo= lic Software=C2=A0=E2= =80=A2 https://symb= olic.software
Sent from office

On Fri, Mar 23, 2018 at 1:28 PM, Alexey Ermi= shkin <scratch@virgilsecurity.com> wrote:
Hi, my name's Alex Ermishkin.
I'm Chief Product Security Officer at Virgil Security, Inc. which focus= es on
delivering end-to-end encryption-based solutions to developers and
businesses.
We are the guys behind NoiseSocket protocol, a TLS alternative without
certificates, which is now in active development together with the author o= f
the Noise Protocol Framework (noiseprotocol.org) and the Signal protocol= ,
Trevor Perrin.
We would like to offer help in implementing MLS drafts along the way. We already have open source SDKs for 9 platforms
(https://github.com/VirgilSecurity) and would like all of = them to support
MLS.
Is it still possible to become a member of the working group?
We could provide real world protocol implementations, test integrations, feedback from the real customers.
Let us know if you'd be interested in talking.

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

--000000000000d2a1ad056814dd09-- From nobody Fri Mar 23 07:13:25 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF49E12D7FC for ; Fri, 23 Mar 2018 07:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, 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 cxx6igi-gZmZ for ; Fri, 23 Mar 2018 07:13:21 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93D6126CBF for ; Fri, 23 Mar 2018 07:13:20 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id u46so12280591wrc.11 for ; Fri, 23 Mar 2018 07:13:20 -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=Nrm4P33XlXuOi91vD4opftEk1NSMHn9rc235/n9mNvs=; b=JYMM+Pmt9G2G45ftUoXgWNLKnijpTsQZMh8gv6KmeMsaZ0dwOFmwhdbHbIzN8eFUon 4s+E9jvBzdo+tusiKpuN8nT7WSmZumuK94JKWTSDDZ2ADjHq3noVM0QlTKXN4TKCUpFr 9Ojv9Oh6KB47uL/RwK9+6cRZGFN09A2MvNHEQmgKGeMuMHY9yFPjjqJt8PuFZrP34KoN 1xnyzBCEI7PjJCfD+KZ1iV5dPFndG740uEkQ3ptwadtMbCVb8vFlWK7IBs+DmfK9AALs YU/LNQjSEq3Z07rHnhqyH8mj7gI/EX3eJdFcRq6Tf+K72uF4LylzvOhi200tKqzSA8ct 917A== 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=Nrm4P33XlXuOi91vD4opftEk1NSMHn9rc235/n9mNvs=; b=bQK9H9ZvIMCMpLHcM4vizxIQda7MvwAL747CG9PKUoMMabHxh6zJ+cUabH/EhT534a Eeis2Ltv8DC2mb+OCEMW7CkgGfJI1Rs3PCh4fjSoOZg7gFMWIBdVNAgiuveP60loNN7p DfLsJhX6F3kTCpi6kjUYDNullt71EbeWxj6apVRzOSgCI740j/P79R4tq0JKnEkN9aSA con9DfLpLCR2RETUwTc1elD4Dx+/QEUuHA0mrF63O5muzaYHSzQBuH6GpvGX3yfzB6yr LJGAZhZ8rCStMOnxvE+oYqTkeJQYvZ7B8BNIksSILwgO08avnqfCzAvLUqFh5iE1vmLK pzGA== X-Gm-Message-State: AElRT7GSqer7mQDPKsf/F31qrfOzIQRbpGmBa+AKHTZJOrEAJNEoc8jO r4ORam/p+syOmkhkMmFN9eOBn0hRRIOjQJP4AEZatVAB X-Google-Smtp-Source: AG47ELvyfyJt5GkDg3prVLAitsSMFGMyPwfe8fIyIc7rethLWjFFr2BjZLUNo4O3p/SvgPXHiqQrlaKd5LJfaIpr0qk= X-Received: by 10.223.226.14 with SMTP id j14mr2384045wri.17.1521814399013; Fri, 23 Mar 2018 07:13:19 -0700 (PDT) MIME-Version: 1.0 References: <006201d3c2aa$dc9fded0$95df9c70$@virgilsecurity.com> In-Reply-To: From: Richard Barnes Date: Fri, 23 Mar 2018 14:13:08 +0000 Message-ID: To: Nadim Kobeissi Cc: Alexey Ermishkin , mls@ietf.org Content-Type: multipart/alternative; boundary="f4f5e80f0674aaf71b0568150623" Archived-At: Subject: Re: [MLS] Virgil Security would like to join the MLS development process X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 14:13:24 -0000 --f4f5e80f0674aaf71b0568150623 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There's no formal membership process here -- just contribute! The only constraint is that you need to declare any patents you're aware of. So yeah, have a look at the docs, send some comments to the list or PRs to the repo, and let us know how your implementation is going! On Fri, Mar 23, 2018, 14:02 Nadim Kobeissi wrote: > Hi Alexey, > I think it's possible for you to simply follow along the MLS development > process, offering suggestions and feedback along the way, same as myself = or > anyone else. > > If you would like to develop implementations, test integration, etc. also= , > that is something you can do out of your own volition as the standard > progresses and matures, without asking for permission or obtaining some > kind of agreement with anyone. Then, you can share your work, progress an= d > findings with the list, and everyone can provide feedback and learn from > your work. > > Regards, > > > > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > Sent from office > > On Fri, Mar 23, 2018 at 1:28 PM, Alexey Ermishkin < > scratch@virgilsecurity.com> wrote: > >> Hi, my name's Alex Ermishkin. >> I'm Chief Product Security Officer at Virgil Security, Inc. which focuse= s >> on >> delivering end-to-end encryption-based solutions to developers and >> businesses. >> We are the guys behind NoiseSocket protocol, a TLS alternative without >> certificates, which is now in active development together with the autho= r >> of >> the Noise Protocol Framework (noiseprotocol.org) and the Signal protocol= , >> Trevor Perrin. >> We would like to offer help in implementing MLS drafts along the way. We >> already have open source SDKs for 9 platforms >> (https://github.com/VirgilSecurity) and would like all of them to suppor= t >> MLS. >> Is it still possible to become a member of the working group? >> We could provide real world protocol implementations, test integrations, >> feedback from the real customers. >> Let us know if you'd be interested in talking. >> >> _______________________________________________ >> 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 > --f4f5e80f0674aaf71b0568150623 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's no formal membership process here -- just con= tribute!=C2=A0 The only constraint is that you need to declare any patents = you're aware of.=C2=A0

So = yeah, have a look at the docs, send some comments to the list or PRs to the= repo, and let us know how your implementation is going!



On Fri, Mar 23, 2018, 14:02 Nadim Kobeissi <na= dim@symbolic.software> wrote:
Hi Alexey,
I think it's possible= for you to simply follow along the MLS development process, offering sugge= stions and feedback along the way, same as myself or anyone else.

If you would like to develop implementations, test integration, etc. al= so, that is something you can do out of your own volition as the standard p= rogresses and matures, without asking for permission or obtaining some kind= of agreement with anyone. Then, you can share your work, progress and find= ings with the list, and everyone can provide feedback and learn from your w= ork.

Regards,



Nadi= m Kobeissi
Symbolic Software=C2=A0=E2=80=A2 https://symbolic.software
Sent from office

On Fri, Mar 23, 2018 at 1:28 PM, Alexey Ermi= shkin <scratch@virgilsecurity.com> wrote:
Hi, my name's Alex Ermishki= n.
I'm Chief Product Security Officer at Virgil Security, Inc. which focus= es on
delivering end-to-end encryption-based solutions to developers and
businesses.
We are the guys behind NoiseSocket protocol, a TLS alternative without
certificates, which is now in active development together with the author o= f
the Noise Protocol Framework (noiseprotocol.org) and the Sign= al protocol,
Trevor Perrin.
We would like to offer help in implementing MLS drafts along the way. We already have open source SDKs for 9 platforms
(https://github.com/VirgilSecurity) and would like a= ll of them to support
MLS.
Is it still possible to become a member of the working group?
We could provide real world protocol implementations, test integrations, feedback from the real customers.
Let us know if you'd be interested in talking.

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

_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--f4f5e80f0674aaf71b0568150623-- From nobody Fri Mar 23 07:35:18 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998F12D86D for ; Fri, 23 Mar 2018 07:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8xbaJwuIo-W for ; Fri, 23 Mar 2018 07:35:15 -0700 (PDT) Received: from VirgilSecurity.com (mail.virgilsecurity.com [199.58.211.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E94E127522 for ; Fri, 23 Mar 2018 07:35:15 -0700 (PDT) Received: from BIGONE (unknown [176.226.240.214]) by VirgilSecurity.com (Postfix) with ESMTPSA id 52BC010515441A; Fri, 23 Mar 2018 10:35:13 -0400 (EDT) From: "Alexey Ermishkin" To: "'Richard Barnes'" , "'Nadim Kobeissi'" Cc: References: <006201d3c2aa$dc9fded0$95df9c70$@virgilsecurity.com> In-Reply-To: Date: Fri, 23 Mar 2018 19:35:10 +0500 Message-ID: <007101d3c2b4$27b76ab0$77264010$@virgilsecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01D3C2DE.108E0EF0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFQnUhlTrg70Cw6gokfMyQnPK03WADm5Hl4AfpBBvSkzSNPMA== Content-Language: ru Archived-At: Subject: Re: [MLS] Virgil Security would like to join the MLS development process X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 14:35:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0072_01D3C2DE.108E0EF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, that=E2=80=99s a good advice. Anyway, you can count on us! =20 From: Richard Barnes =20 Sent: Friday, March 23, 2018 7:13 PM To: Nadim Kobeissi Cc: Alexey Ermishkin ; mls@ietf.org Subject: Re: [MLS] Virgil Security would like to join the MLS = development process =20 There's no formal membership process here -- just contribute! The only = constraint is that you need to declare any patents you're aware of.=20 =20 So yeah, have a look at the docs, send some comments to the list or PRs = to the repo, and let us know how your implementation is going! =20 =20 =20 On Fri, Mar 23, 2018, 14:02 Nadim Kobeissi > wrote: Hi Alexey, I think it's possible for you to simply follow along the MLS development = process, offering suggestions and feedback along the way, same as myself = or anyone else. If you would like to develop implementations, test integration, etc. = also, that is something you can do out of your own volition as the = standard progresses and matures, without asking for permission or = obtaining some kind of agreement with anyone. Then, you can share your = work, progress and findings with the list, and everyone can provide = feedback and learn from your work. Regards, =20 Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office =20 On Fri, Mar 23, 2018 at 1:28 PM, Alexey Ermishkin = > wrote: Hi, my name's Alex Ermishkin. I'm Chief Product Security Officer at Virgil Security, Inc. which = focuses on delivering end-to-end encryption-based solutions to developers and businesses. We are the guys behind NoiseSocket protocol, a TLS alternative without certificates, which is now in active development together with the = author of the Noise Protocol Framework (noiseprotocol.org = ) and the Signal protocol, Trevor Perrin. We would like to offer help in implementing MLS drafts along the way. We already have open source SDKs for 9 platforms (https://github.com/VirgilSecurity) and would like all of them to = support MLS. Is it still possible to become a member of the working group? We could provide real world protocol implementations, test integrations, feedback from the real customers. Let us know if you'd be interested in talking. _______________________________________________ MLS mailing list MLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/mls =20 _______________________________________________ MLS mailing list MLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/mls ------=_NextPart_000_0072_01D3C2DE.108E0EF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks, that=E2=80=99s = a good advice. Anyway, you can count on us!

 

From: Richard Barnes <rlb@ipv.sx> =
Sent: Friday, March 23, 2018 7:13 PM
To: Nadim = Kobeissi <nadim@symbolic.software>
Cc: Alexey Ermishkin = <scratch@virgilsecurity.com>; mls@ietf.org
Subject: Re: = [MLS] Virgil Security would like to join the MLS development = process

 

There's no formal membership process here -- just = contribute!  The only constraint is that you need to declare any = patents you're aware of. 

 

So yeah, have a look at the docs, send some comments = to the list or PRs to the repo, and let us know how your implementation = is going!

 

 

 

On = Fri, Mar 23, 2018, 14:02 Nadim Kobeissi <nadim@symbolic.software> = wrote:

Hi Alexey,

I think it's possible for you to simply = follow along the MLS development process, offering suggestions and = feedback along the way, same as myself or anyone = else.

If you would like to develop = implementations, test integration, etc. also, that is something you can = do out of your own volition as the standard progresses and matures, = without asking for permission or obtaining some kind of agreement with = anyone. Then, you can share your work, progress and findings with the = list, and everyone can provide feedback and learn from your = work.

Regards,

 


Nadim Kobeissi

Symbolic Software =E2=80=A2 https://symbolic.software

Sent from = office

 

On Fri, = Mar 23, 2018 at 1:28 PM, Alexey Ermishkin <scratch@virgilsecurity.com> = wrote:

Hi, my = name's Alex Ermishkin.
I'm Chief Product Security Officer at Virgil = Security, Inc. which focuses on
delivering end-to-end = encryption-based solutions to developers and
businesses.
We are = the guys behind NoiseSocket protocol, a TLS alternative = without
certificates, which is now in active development together = with the author of
the Noise Protocol Framework (noiseprotocol.org) and the Signal = protocol,
Trevor Perrin.
We would like to offer help in = implementing MLS drafts along the way. We
already have open source = SDKs for 9 platforms
(https://github.com/VirgilSecurity) and would like = all of them to support
MLS.
Is it still possible to become a = member of the working group?
We could provide real world protocol = implementations, test integrations,
feedback from the real = customers.
Let us know if you'd be interested in = talking.

_______________________________________________
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

------=_NextPart_000_0072_01D3C2DE.108E0EF0-- From nobody Sat Mar 24 04:28:20 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A6E1241F8 for ; Sat, 24 Mar 2018 04:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzRBZ8DmFuMm for ; Sat, 24 Mar 2018 04:28:16 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB941201F2 for ; Sat, 24 Mar 2018 04:28:16 -0700 (PDT) Received: from fifthhorseman.net (c-66-31-31-124.hsd1.ma.comcast.net [66.31.31.124]) by che.mayfirst.org (Postfix) with ESMTPSA id DDB3DF99A for ; Sat, 24 Mar 2018 07:28:15 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3900020046; Sat, 24 Mar 2018 11:27:28 +0000 (GMT) From: Daniel Kahn Gillmor To: mls@ietf.org Date: Sat, 24 Mar 2018 07:27:24 -0400 Message-ID: <87r2o9n277.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 11:28:19 -0000 --=-=-= Content-Type: text/plain Thanks for all the work that has gone into the proposed MLS architecture and protocol drafts already. As we move toward working group formation, i'm a little bit concerned that the ostensible name of the project ("message layer security") doesn't adequately describe the most salient features. We spent most of the time at the BoF in IETF 101 London talking about the design of the group key agreement scheme and the strong cryptographic properties we want it to provide -- and i suspect that most of the work in any formed WG will center around that problem. So it seems odd to me that the word "group" doesn't appear in the name "MLS". I'm no good at acronyms, but i'll just throw out two alternatives: MSG: Messaging Security for Groups MESSAGE: Message Encryption and Security Standard for Asynchronous Group Environments I hope since the WG isn't yet formed, it's not too late to consider a change to the name. We ought to be up front about the group-specific context that we're talking about here, as we already have a security layer that works for messages passing between two endpoints synchronously (TLS) and it'd be nice to clearly carve up the territory. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCWrY2HAAKCRBsHx7ezFD6 U9VwAQDoEi+4wx/eEWhuphdZihDnvTIrDbsegOR7FMZH39aA/gEAn9qb8HhjPad1 W3L4QCujQpI1PouO2Y4m6V5JMAo8Sg4= =9lNI -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 24 06:15:15 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD7128D2E for ; Sat, 24 Mar 2018 06:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaFm-zyxP_Tk for ; Sat, 24 Mar 2018 06:15:12 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E341201F2 for ; Sat, 24 Mar 2018 06:15:11 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id a22-v6so22050623lfg.9 for ; Sat, 24 Mar 2018 06:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dFHgFTfvJlSjXDaf+DbKQzTeO5MLjBPuD3Z+t8TKNw8=; b=J5N0ToZJswxsr8FAjAccjHQCG7TK6jY/szWNXO5yvRUndldrKl4DJ5MYRAiQot0pUe T/UY0+hOj545CNCA2eKsoFcvT3sRxB0NGL7Ka1skqxeVrRreUXffsxBOJytuZLwopksB J8BhEyE49axfvhYlkclf4De5Ak7ndPg52hGcRN2dxXdNAAZCokXM/c/Gak1vEFneTivs Vcl4e3vNvpzH8vsTfMzIBYB44/f6F1NkgYwBXRKmPW6lRtbLxlWZpID1t7wkNi30vmqz DCN0i4SbuA5E8Ou+yifzgKWnlhEPbj7a4jZTyi8A31kgFh7fiWhNyuxg0LYM5vFEiINn WfKw== 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=dFHgFTfvJlSjXDaf+DbKQzTeO5MLjBPuD3Z+t8TKNw8=; b=lahxp8Le61F3FbSvePG8lldXlmOqRl06H6qyn19Ctiabet8ecrHpXH4RXhRmmSgMgx FyEIz5/H0sFf4224p4DNujzHDTby4zlCo0Mu8A7q0KS+LgsGCgmcNDrMt2JXN3Ln8sfi hHl+CXAd66ZSb5re4CShmsQHa2OEEKIjtx4Gp9ErsSPwiSLGncYrRU3/uh9vrd2+6U3I yL7AwqcGVQ2H5IZ4UdFwu3bKQd2wvLqmkhnzQ5RM6YYKXYhaE5FY1IPcnW85K/vvybdh VWjrIarnv1/fBuq5DmQIU/bUmossLzgk5IiXYREcahSqwF/wEQDfGVXzsGzIInP2Ix15 JEmw== X-Gm-Message-State: AElRT7EiIpULEg4GIAHqdAV5uiJWun5l7TrGDKTcRS6PajZltIFpC6Yc uakyKkvApllAtYJljTSBWs3jnSyM5fq9R8UC82Y= X-Google-Smtp-Source: AG47ELsPySNhCTPIc/4gWCnSo+5mASOKij68bv8yfigaVo4T9N5+udFOeANpa9GP22PLLjeZ73Wx+Q5pbpYhL7Cbeyg= X-Received: by 10.46.2.134 with SMTP id y6mr13483599lje.118.1521897309797; Sat, 24 Mar 2018 06:15:09 -0700 (PDT) MIME-Version: 1.0 References: <87r2o9n277.fsf@fifthhorseman.net> In-Reply-To: <87r2o9n277.fsf@fifthhorseman.net> From: Shivan Date: Sat, 24 Mar 2018 13:14:58 +0000 Message-ID: To: Daniel Kahn Gillmor Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1909b889028b056828548c" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 13:15:14 -0000 --94eb2c1909b889028b056828548c Content-Type: text/plain; charset="UTF-8" +1 the name seems to be inspired by TLS but the drafts concern themselves explicitly with group messaging, not messaging as a whole. On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn Gillmor wrote: > Thanks for all the work that has gone into the proposed MLS architecture > and protocol drafts already. > > As we move toward working group formation, i'm a little bit concerned > that the ostensible name of the project ("message layer security") > doesn't adequately describe the most salient features. > > We spent most of the time at the BoF in IETF 101 London talking about > the design of the group key agreement scheme and the strong > cryptographic properties we want it to provide -- and i suspect that > most of the work in any formed WG will center around that problem. > > So it seems odd to me that the word "group" doesn't appear in the name > "MLS". > > I'm no good at acronyms, but i'll just throw out two alternatives: > > MSG: Messaging Security for Groups > > MESSAGE: Message Encryption and Security Standard for Asynchronous Group > Environments > > I hope since the WG isn't yet formed, it's not too late to consider a > change to the name. We ought to be up front about the group-specific > context that we're talking about here, as we already have a security > layer that works for messages passing between two endpoints > synchronously (TLS) and it'd be nice to clearly carve up the territory. > > --dkg > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --94eb2c1909b889028b056828548c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 the name seems to be inspired by TLS but the drafts co= ncern themselves explicitly with group messaging, not messaging as a whole.= =C2=A0=C2=A0

On Sat, M= ar 24, 2018, 11:28 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Thanks for all the work that has gone into the proposed MLS a= rchitecture
and protocol drafts already.

As we move toward working group formation, i'm a little bit concerned that the ostensible name of the project ("message layer security"= )
doesn't adequately describe the most salient features.

We spent most of the time at the BoF in IETF 101 London talking about
the design of the group key agreement scheme and the strong
cryptographic properties we want it to provide -- and i suspect that
most of the work in any formed WG will center around that problem.

So it seems odd to me that the word "group" doesn't appear in= the name
"MLS".

I'm no good at acronyms, but i'll just throw out two alternatives:<= br>
=C2=A0 MSG: Messaging Security for Groups

=C2=A0 MESSAGE: Message Encryption and Security Standard for Asynchronous G= roup Environments

I hope since the WG isn't yet formed, it's not too late to consider= a
change to the name.=C2=A0 We ought to be up front about the group-specific<= br> context that we're talking about here, as we already have a security layer that works for messages passing between two endpoints
synchronously (TLS) and it'd be nice to clearly carve up the territory.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg
_______________________________________________
MLS mailing list
MLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/mls
--94eb2c1909b889028b056828548c-- From nobody Sat Mar 24 06:43:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69F6129C51 for ; Sat, 24 Mar 2018 06:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=A48I4oGe; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=T1c3Cwzw 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 lPuQvAOsP5Ep for ; Sat, 24 Mar 2018 06:43:45 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F121A1201F2 for ; Sat, 24 Mar 2018 06:43:44 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w2ODg4ot014701; Sat, 24 Mar 2018 06:43:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=+tJvhtH63SQLlgDBpo8DC6YbpcIUVCf2/MoS8SRkGII=; b=A48I4oGevxLdwLEpT1fGpFUQD54ioVoGjlQNYcHfpbpIEdR2IrPUVOmlt7/X21nQet1k 8+24jvngH6o81RzErGYNwCHZ6uhT5OngLZuxsvO0mxpBwjDJXt1WXe6GKQ0Dgs9DwDTF 5kKf7Ns3+tM4EphUPk/mp2BdaWEJevDJFis= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2gwjbmgd34-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2018 06:43:41 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.11) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 06:43:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+tJvhtH63SQLlgDBpo8DC6YbpcIUVCf2/MoS8SRkGII=; b=T1c3CwzwqBJhsXNyzxe1w9VV/5DfJOM64igLsPStyUc06JJXl+Y6epRjdvcQegbrK63HcFXCD2YB2iLzev0vH19odXQki1xobOY3M6B5fdSDncc0ec9yX+8mHIbq5/2No7Wj4xGkyecFgUydm/PBVptXj1A4WwGCUPXwPdEzlOM= Received: from BN6PR15MB1745.namprd15.prod.outlook.com (10.174.238.135) by BN6PR15MB1411.namprd15.prod.outlook.com (10.172.150.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.10; Sat, 24 Mar 2018 13:43:37 +0000 Received: from BN6PR15MB1745.namprd15.prod.outlook.com ([10.174.238.135]) by BN6PR15MB1745.namprd15.prod.outlook.com ([10.174.238.135]) with mapi id 15.20.0609.012; Sat, 24 Mar 2018 13:43:37 +0000 From: Jon Millican To: Shivan CC: Daniel Kahn Gillmor , "mls@ietf.org" Thread-Topic: [MLS] MLS: the WG name should include "group" Thread-Index: AQHTw2NOh1i9TiA6Lk6ldNKeXbExraPfXXAAgAAIAt0= Date: Sat, 24 Mar 2018 13:43:37 +0000 Message-ID: References: <87r2o9n277.fsf@fifthhorseman.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.39.102.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR15MB1411; 7:5WsZsGsitvNbOZ5bGOycKrVspvozNa9zCKsw9lwgrCRDh3Vy9/1OODh5w+HREm+PS0HhzvQ8gRPba9MZsI4bBBPIKg4qoc1Rff0RKyfeVX9P9WBqyjVLH76+o7WFOfreHTBI41piUjgtf3qFZ/O2Rq3P/s8o8bBYPlqnEVWwOoeNi109dxbp/ik2hkgtxbVDFdHuuTyDWiyRE8r/TXCyU8Il88c8V37BLJMJh7befOHHPzD64Xf5eluhH/BWORyt; 20:794L9RZxQ+YREZ9ZFhSLmiifRBFSrV6xl4YJ84641LgSKGToMAXGDBVM7ln0aXJPgXneH3TH6kJmbr5/8qTEcqeyT7lfUD2Ii/xV1BEGnGr204Mqhf8wO7hoWCISn3yRlC7xNdZURcbaVzfguM9rNnky0v1QyOZ5PUZnFq+MF7o= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 266a7eae-7a0e-4f00-543f-08d5918d3efd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR15MB1411; x-ms-traffictypediagnostic: BN6PR15MB1411: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR15MB1411; BCL:0; PCL:0; RULEID:; SRVR:BN6PR15MB1411; x-forefront-prvs: 0621E7E436 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(39380400002)(376002)(199004)(189003)(60444003)(69224002)(97736004)(33656002)(81156014)(66066001)(6916009)(8936002)(68736007)(8676002)(82746002)(39060400002)(2616005)(81166006)(5660300001)(105586002)(4326008)(229853002)(3846002)(6116002)(6436002)(2900100001)(6486002)(36756003)(55236004)(26005)(102836004)(25786009)(2906002)(7736002)(106356001)(3280700002)(478600001)(53936002)(6246003)(53546011)(76176011)(6506007)(99286004)(54906003)(966005)(77096007)(6306002)(86362001)(236005)(316002)(14454004)(446003)(186003)(59450400001)(11346002)(3660700001)(606006)(575784001)(6512007)(54896002)(83716003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR15MB1411; H:BN6PR15MB1745.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0QMlCbbXaOE4odbpqBF6G6gIkcsS3z4A5/zqjQE/XdhbcszcXtzZurTG4laKuRiGW7qs0Ud6dv8iYAh8SfeFxYdTMRv8NYyNLBiiKVfTqxWMlpfrUxeSPeCya59abSM1ZHJKTdSJ9h8S0jUTmI7zV6D+mmoLGQx+ZKCQmdn6Gm6FqdiDasAjLjzoUffchbHGvhjEGFhzXGTlzVFJlEikRKL7UPOaNpWbQYeJKozCnHZgs92vXQAcNA0CzJQPHphrLUmmE4czO6i4mwarYaczH1rrKUC+ZoFhlDA61O40pi6VAdPTKiQV9zh8d3LXCMSbzgluiiAKt7voWi0vm5P0vw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_FD644F8C38BA4573B7F6EF6AC4FEB57Cfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 266a7eae-7a0e-4f00-543f-08d5918d3efd X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2018 13:43:37.4117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR15MB1411 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-24_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 13:43:48 -0000 --_000_FD644F8C38BA4573B7F6EF6AC4FEB57Cfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciByYWlzaW5nIHRoaXMgcG9pbnQuIEknbSBhbHNvIG5vIGdvb2QgYXQgbmFtaW5n LCBidXQgYWdyZWUgdGhhdCB0aGVyZSdzIHBvdGVudGlhbCBzY29wZSB0byBuYW1lIG1vcmUgY2xl YXJseS4gQSBjb3VwbGUgb2YgcG9pbnRzIGluIHJlc3BvbnNlIHRvIHRoZSBzcGVjaWZpYyBpc3N1 ZXMgeW91IHJhaXNlZCB0aG91Z2g6DQoNCldoaWxlIG1vc3Qgb2YgdGhlIGRpc2N1c3Npb24gaGFz IGZvY3VzZWQgb24gZ3JvdXBzLCBteSBmZWVsaW5nIGlzIHRoYXQgdGhpcyBpcyBiZWNhdXNlIGdy b3VwIGlzIGEgbW9yZSBjaGFsbGVuZ2luZyBzdXBlcnNldCBvZiB0aGUgcGFpcndpc2UgY2FzZTsg YW5kIHdlIHNob3VsZCBzdGlsbCBjYXJlIGFib3V0IHBhaXJ3aXNlIG1lc3NhZ2luZy4gSW4gdGhl IHBhaXJ3aXNlIGNhc2UgSSB0aGluayB0aGUgbWFpbiBkaWZmZXJlbnRpYXRvciBjb21wYXJlZCB3 aXRoIFRMUyBpcyB0aGUgcmVxdWlyZW1lbnQgZm9yIGFzeW5jaHJvbmljaXR5OyBzbyBpZiB3ZSdy ZSBjbGVhcmx5IGNhcnZpbmcgdXAgdGhlIHRlcnJpdG9yeSBpdCBtaWdodCBtYWtlIHNlbnNlIHRv IGhpZ2hsaWdodCB0aGlzLg0KDQpKdXN0IG15IDJjIHRob3VnaC4gSSBoYXZlIG5vIG9iamVjdGlv biBhdCBhbGwgdG8gY2hhbmdpbmcgdGhlIG5hbWUsIGFuZCBjZXJ0YWlubHkgYWdyZWUgdGhhdCBn cm91cCBzdXBwb3J0IGlzIGEgY3J1Y2lhbCBhc3BlY3QgdGhhdCBjb3VsZCBiZSB3b3J0aCBoaWdo bGlnaHRpbmcuDQoNCkpvbg0KDQpPbiAyNCBNYXIgMjAxOCwgYXQgMTM6MTUsIFNoaXZhbiA8c2hp dmFua2F1bC4xOTkzQGdtYWlsLmNvbTxtYWlsdG86c2hpdmFua2F1bC4xOTkzQGdtYWlsLmNvbT4+ IHdyb3RlOg0KDQorMSB0aGUgbmFtZSBzZWVtcyB0byBiZSBpbnNwaXJlZCBieSBUTFMgYnV0IHRo ZSBkcmFmdHMgY29uY2VybiB0aGVtc2VsdmVzIGV4cGxpY2l0bHkgd2l0aCBncm91cCBtZXNzYWdp bmcsIG5vdCBtZXNzYWdpbmcgYXMgYSB3aG9sZS4NCg0KT24gU2F0LCBNYXIgMjQsIDIwMTgsIDEx OjI4IEFNIERhbmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldDxtYWlsdG86 ZGtnQGZpZnRoaG9yc2VtYW4ubmV0Pj4gd3JvdGU6DQpUaGFua3MgZm9yIGFsbCB0aGUgd29yayB0 aGF0IGhhcyBnb25lIGludG8gdGhlIHByb3Bvc2VkIE1MUyBhcmNoaXRlY3R1cmUNCmFuZCBwcm90 b2NvbCBkcmFmdHMgYWxyZWFkeS4NCg0KQXMgd2UgbW92ZSB0b3dhcmQgd29ya2luZyBncm91cCBm b3JtYXRpb24sIGknbSBhIGxpdHRsZSBiaXQgY29uY2VybmVkDQp0aGF0IHRoZSBvc3RlbnNpYmxl IG5hbWUgb2YgdGhlIHByb2plY3QgKCJtZXNzYWdlIGxheWVyIHNlY3VyaXR5IikNCmRvZXNuJ3Qg YWRlcXVhdGVseSBkZXNjcmliZSB0aGUgbW9zdCBzYWxpZW50IGZlYXR1cmVzLg0KDQpXZSBzcGVu dCBtb3N0IG9mIHRoZSB0aW1lIGF0IHRoZSBCb0YgaW4gSUVURiAxMDEgTG9uZG9uIHRhbGtpbmcg YWJvdXQNCnRoZSBkZXNpZ24gb2YgdGhlIGdyb3VwIGtleSBhZ3JlZW1lbnQgc2NoZW1lIGFuZCB0 aGUgc3Ryb25nDQpjcnlwdG9ncmFwaGljIHByb3BlcnRpZXMgd2Ugd2FudCBpdCB0byBwcm92aWRl IC0tIGFuZCBpIHN1c3BlY3QgdGhhdA0KbW9zdCBvZiB0aGUgd29yayBpbiBhbnkgZm9ybWVkIFdH IHdpbGwgY2VudGVyIGFyb3VuZCB0aGF0IHByb2JsZW0uDQoNClNvIGl0IHNlZW1zIG9kZCB0byBt ZSB0aGF0IHRoZSB3b3JkICJncm91cCIgZG9lc24ndCBhcHBlYXIgaW4gdGhlIG5hbWUNCiJNTFMi Lg0KDQpJJ20gbm8gZ29vZCBhdCBhY3JvbnltcywgYnV0IGknbGwganVzdCB0aHJvdyBvdXQgdHdv IGFsdGVybmF0aXZlczoNCg0KICBNU0c6IE1lc3NhZ2luZyBTZWN1cml0eSBmb3IgR3JvdXBzDQoN CiAgTUVTU0FHRTogTWVzc2FnZSBFbmNyeXB0aW9uIGFuZCBTZWN1cml0eSBTdGFuZGFyZCBmb3Ig QXN5bmNocm9ub3VzIEdyb3VwIEVudmlyb25tZW50cw0KDQpJIGhvcGUgc2luY2UgdGhlIFdHIGlz bid0IHlldCBmb3JtZWQsIGl0J3Mgbm90IHRvbyBsYXRlIHRvIGNvbnNpZGVyIGENCmNoYW5nZSB0 byB0aGUgbmFtZS4gIFdlIG91Z2h0IHRvIGJlIHVwIGZyb250IGFib3V0IHRoZSBncm91cC1zcGVj aWZpYw0KY29udGV4dCB0aGF0IHdlJ3JlIHRhbGtpbmcgYWJvdXQgaGVyZSwgYXMgd2UgYWxyZWFk eSBoYXZlIGEgc2VjdXJpdHkNCmxheWVyIHRoYXQgd29ya3MgZm9yIG1lc3NhZ2VzIHBhc3Npbmcg YmV0d2VlbiB0d28gZW5kcG9pbnRzDQpzeW5jaHJvbm91c2x5IChUTFMpIGFuZCBpdCdkIGJlIG5p Y2UgdG8gY2xlYXJseSBjYXJ2ZSB1cCB0aGUgdGVycml0b3J5Lg0KDQogICAgICAgIC0tZGtnDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxp bmcgbGlzdA0KTUxTQGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21sczxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21s cyZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZFcU1h ODRRJm09cTVLUDFBSlV1LTRpci0zOXlyUVdFTGUxZ1VMWjdVUWJldmZEQnJncjBzcyZzPWpsUENU azlmQ0RBdkt0NmwyRHVGS1lMSm9STEVMX0tYVjdsUEhodGxBM00mZT0+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTUxTIG1haWxpbmcgbGlzdA0KTUxT QGlldGYub3JnPG1haWx0bzpNTFNAaWV0Zi5vcmc+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X21scyZkPUR3SUNBZyZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1NMENWRUp5ZEJWVVhfYnZF cU1hODRRJm09cTVLUDFBSlV1LTRpci0zOXlyUVdFTGUxZ1VMWjdVUWJldmZEQnJncjBzcyZzPWps UENUazlmQ0RBdkt0NmwyRHVGS1lMSm9STEVMX0tYVjdsUEhodGxBM00mZT0NCg== --_000_FD644F8C38BA4573B7F6EF6AC4FEB57Cfbcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PlRoYW5rcyBmb3IgcmFpc2luZyB0aGlzIHBvaW50LiBJJ20gYWxzbyBubyBnb29kIGF0IG5h bWluZywgYnV0IGFncmVlIHRoYXQgdGhlcmUncyBwb3RlbnRpYWwgc2NvcGUgdG8gbmFtZSBtb3Jl IGNsZWFybHkuIEEgY291cGxlIG9mIHBvaW50cyBpbiByZXNwb25zZSB0byB0aGUgc3BlY2lmaWMg aXNzdWVzIHlvdSByYWlzZWQgdGhvdWdoOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCldoaWxl IG1vc3Qgb2YgdGhlIGRpc2N1c3Npb24gaGFzIGZvY3VzZWQgb24gZ3JvdXBzLCBteSBmZWVsaW5n IGlzIHRoYXQgdGhpcyBpcyBiZWNhdXNlIGdyb3VwIGlzIGEgbW9yZSBjaGFsbGVuZ2luZyBzdXBl cnNldCBvZiB0aGUgcGFpcndpc2UgY2FzZTsgYW5kIHdlIHNob3VsZCBzdGlsbCBjYXJlIGFib3V0 IHBhaXJ3aXNlIG1lc3NhZ2luZy4gSW4gdGhlIHBhaXJ3aXNlIGNhc2UgSSB0aGluayB0aGUgbWFp biBkaWZmZXJlbnRpYXRvciBjb21wYXJlZA0KIHdpdGggVExTIGlzIHRoZSByZXF1aXJlbWVudCBm b3IgYXN5bmNocm9uaWNpdHk7IHNvIGlmIHdlJ3JlIGNsZWFybHkgY2FydmluZyB1cCB0aGUgdGVy cml0b3J5IGl0IG1pZ2h0IG1ha2Ugc2Vuc2UgdG8gaGlnaGxpZ2h0IHRoaXMuDQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5KdXN0IG15IDJjIHRob3VnaC4gSSBoYXZlIG5vIG9iamVjdGlvbiBhdCBh bGwgdG8gY2hhbmdpbmcgdGhlIG5hbWUsIGFuZCBjZXJ0YWlubHkgYWdyZWUgdGhhdCBncm91cCBz dXBwb3J0IGlzIGEgY3J1Y2lhbCBhc3BlY3QgdGhhdCBjb3VsZCBiZSB3b3J0aCBoaWdobGlnaHRp bmcuPGJyPg0KPGRpdj48YnI+DQo8ZGl2PkpvbjwvZGl2Pg0KPGRpdj48YnI+DQpPbiAyNCBNYXIg MjAxOCwgYXQgMTM6MTUsIFNoaXZhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoaXZhbmthdWwuMTk5 M0BnbWFpbC5jb20iPnNoaXZhbmthdWwuMTk5M0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYgZGly PSJhdXRvIj4mIzQzOzEgdGhlIG5hbWUgc2VlbXMgdG8gYmUgaW5zcGlyZWQgYnkgVExTIGJ1dCB0 aGUgZHJhZnRzIGNvbmNlcm4gdGhlbXNlbHZlcyBleHBsaWNpdGx5IHdpdGggZ3JvdXAgbWVzc2Fn aW5nLCBub3QgbWVzc2FnaW5nIGFzIGEgd2hvbGUuJm5ic3A7Jm5ic3A7PC9kaXY+DQo8YnI+DQo8 ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIj5PbiBTYXQsIE1hciAyNCwg MjAxOCwgMTE6MjggQU0gRGFuaWVsIEthaG4gR2lsbG1vciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRr Z0BmaWZ0aGhvcnNlbWFuLm5ldCI+ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PC9hPiZndDsgd3JvdGU6 PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NClRoYW5rcyBmb3IgYWxsIHRoZSB3b3JrIHRoYXQgaGFzIGdvbmUgaW50byB0aGUgcHJvcG9z ZWQgTUxTIGFyY2hpdGVjdHVyZTxicj4NCmFuZCBwcm90b2NvbCBkcmFmdHMgYWxyZWFkeS48YnI+ DQo8YnI+DQpBcyB3ZSBtb3ZlIHRvd2FyZCB3b3JraW5nIGdyb3VwIGZvcm1hdGlvbiwgaSdtIGEg bGl0dGxlIGJpdCBjb25jZXJuZWQ8YnI+DQp0aGF0IHRoZSBvc3RlbnNpYmxlIG5hbWUgb2YgdGhl IHByb2plY3QgKCZxdW90O21lc3NhZ2UgbGF5ZXIgc2VjdXJpdHkmcXVvdDspPGJyPg0KZG9lc24n dCBhZGVxdWF0ZWx5IGRlc2NyaWJlIHRoZSBtb3N0IHNhbGllbnQgZmVhdHVyZXMuPGJyPg0KPGJy Pg0KV2Ugc3BlbnQgbW9zdCBvZiB0aGUgdGltZSBhdCB0aGUgQm9GIGluIElFVEYgMTAxIExvbmRv biB0YWxraW5nIGFib3V0PGJyPg0KdGhlIGRlc2lnbiBvZiB0aGUgZ3JvdXAga2V5IGFncmVlbWVu dCBzY2hlbWUgYW5kIHRoZSBzdHJvbmc8YnI+DQpjcnlwdG9ncmFwaGljIHByb3BlcnRpZXMgd2Ug d2FudCBpdCB0byBwcm92aWRlIC0tIGFuZCBpIHN1c3BlY3QgdGhhdDxicj4NCm1vc3Qgb2YgdGhl IHdvcmsgaW4gYW55IGZvcm1lZCBXRyB3aWxsIGNlbnRlciBhcm91bmQgdGhhdCBwcm9ibGVtLjxi cj4NCjxicj4NClNvIGl0IHNlZW1zIG9kZCB0byBtZSB0aGF0IHRoZSB3b3JkICZxdW90O2dyb3Vw JnF1b3Q7IGRvZXNuJ3QgYXBwZWFyIGluIHRoZSBuYW1lPGJyPg0KJnF1b3Q7TUxTJnF1b3Q7Ljxi cj4NCjxicj4NCkknbSBubyBnb29kIGF0IGFjcm9ueW1zLCBidXQgaSdsbCBqdXN0IHRocm93IG91 dCB0d28gYWx0ZXJuYXRpdmVzOjxicj4NCjxicj4NCiZuYnNwOyBNU0c6IE1lc3NhZ2luZyBTZWN1 cml0eSBmb3IgR3JvdXBzPGJyPg0KPGJyPg0KJm5ic3A7IE1FU1NBR0U6IE1lc3NhZ2UgRW5jcnlw dGlvbiBhbmQgU2VjdXJpdHkgU3RhbmRhcmQgZm9yIEFzeW5jaHJvbm91cyBHcm91cCBFbnZpcm9u bWVudHM8YnI+DQo8YnI+DQpJIGhvcGUgc2luY2UgdGhlIFdHIGlzbid0IHlldCBmb3JtZWQsIGl0 J3Mgbm90IHRvbyBsYXRlIHRvIGNvbnNpZGVyIGE8YnI+DQpjaGFuZ2UgdG8gdGhlIG5hbWUuJm5i c3A7IFdlIG91Z2h0IHRvIGJlIHVwIGZyb250IGFib3V0IHRoZSBncm91cC1zcGVjaWZpYzxicj4N CmNvbnRleHQgdGhhdCB3ZSdyZSB0YWxraW5nIGFib3V0IGhlcmUsIGFzIHdlIGFscmVhZHkgaGF2 ZSBhIHNlY3VyaXR5PGJyPg0KbGF5ZXIgdGhhdCB3b3JrcyBmb3IgbWVzc2FnZXMgcGFzc2luZyBi ZXR3ZWVuIHR3byBlbmRwb2ludHM8YnI+DQpzeW5jaHJvbm91c2x5IChUTFMpIGFuZCBpdCdkIGJl IG5pY2UgdG8gY2xlYXJseSBjYXJ2ZSB1cCB0aGUgdGVycml0b3J5Ljxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLWRrZzxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTUxTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpNTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiByZWw9Im5vcmVmZXJyZXIi Pk1MU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X21scyZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENW RUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXE1S1AxQUpVdS00aXItMzl5clFXRUxlMWdVTFo3VVFi ZXZmREJyZ3Iwc3MmYW1wO3M9amxQQ1RrOWZDREF2S3Q2bDJEdUZLWUxKb1JMRUxfS1hWN2xQSGh0 bEEzTSZhbXA7ZT0iIHJlbD0ibm9yZWZlcnJlciBub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbHM8L2E+PGJyPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj5NTFMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4N CjxzcGFuPjxhIGhyZWY9Im1haWx0bzpNTFNAaWV0Zi5vcmciPk1MU0BpZXRmLm9yZzwvYT48L3Nw YW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmYW1w O2Q9RHdJQ0FnJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9TTBDVkVKeWRCVlVY X2J2RXFNYTg0USZhbXA7bT1xNUtQMUFKVXUtNGlyLTM5eXJRV0VMZTFnVUxaN1VRYmV2ZkRCcmdy MHNzJmFtcDtzPWpsUENUazlmQ0RBdkt0NmwyRHVGS1lMSm9STEVMX0tYVjdsUEhodGxBM00mYW1w O2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX21scyZhbXA7ZD1Ed0lDQWcmYW1wO2M9NVZE MFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1NMENWRUp5ZEJWVVhfYnZFcU1hODRRJmFtcDttPXE1 S1AxQUpVdS00aXItMzl5clFXRUxlMWdVTFo3VVFiZXZmREJyZ3Iwc3MmYW1wO3M9amxQQ1RrOWZD REF2S3Q2bDJEdUZLWUxKb1JMRUxfS1hWN2xQSGh0bEEzTSZhbXA7ZT08L2E+PC9zcGFuPjxicj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_FD644F8C38BA4573B7F6EF6AC4FEB57Cfbcom_-- From nobody Sat Mar 24 07:05:46 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B38126DD9 for ; Sat, 24 Mar 2018 07:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=dsORbUFB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IRkShPD9 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 nUnyLLzj3is7 for ; Sat, 24 Mar 2018 07:05:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB011201F2 for ; Sat, 24 Mar 2018 07:05:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DC33320BB9 for ; Sat, 24 Mar 2018 10:05:39 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Sat, 24 Mar 2018 10:05:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=h/PPC2x+G1RXn03ijFZwDSeKLJ xsj1n5br/9NEBepoc=; b=dsORbUFBAmoMNYp03vWWT5Oa7IhAqOv1McL/U5qwkU j6OlCn7UW//LX6zQAuU0dAsgqLUOEskCB4B1OU+83jLbiMyeAqJfEhXd4jbBbCYh taxs3EcKID8EiQqF8bLjlG9mirGUYU8m0KVaqczf9DU/n1eUS6SmLdomCbvB63bj M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=h/PPC2 x+G1RXn03ijFZwDSeKLJxsj1n5br/9NEBepoc=; b=IRkShPD9p38qr1GEbeLgs9 iN9ZwxrN+57bADTfkjokDrKdKRHhxbor8S0LR2baoV/uSPoeMFnQKdcXraAbDGMH BbNva18ygcFL8msgmsEoUZiCminA4lN/dIxYLXlhf000Rwz3CDX+ogmX4HrNSIBy DzI9w0KKSIGU1+ps6fKYg1sFoEUDNLN90xhjIPUAaiciULwXRr3/rcyRp+NxEtjl YDX70xHVWlRsBBfVqMs3p5dPvg1zev5ONR7JFUDxRZu3lOVul1jPhxbXpfM2hVU7 lZog+SJFgOGSh+bOdx6uM+m+JJGKA7FtxE9goKCCn2FUgmJICqsvYAW9BL8BAELQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B2BFF9E124; Sat, 24 Mar 2018 10:05:39 -0400 (EDT) Message-Id: <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> From: "Katriel Cohn-Gordon" To: mls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152190033921141480" X-Mailer: MessagingEngine.com Webmail Interface - ajax-5ce6c4ba References: <87r2o9n277.fsf@fifthhorseman.net> Date: Sat, 24 Mar 2018 14:05:39 +0000 In-Reply-To: Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 14:05:44 -0000 This is a multi-part message in MIME format. --_----------=_152190033921141480 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" +1 I have no strong feelings regarding the name, but I do think we are working on groups *because* you need them for general messaging. Katriel On Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrote: > Thanks for raising this point. I'm also no good at naming, but agree > that there's potential scope to name more clearly. A couple of points > in response to the specific issues you raised though:> > While most of the discussion has focused on groups, my feeling is that > this is because group is a more challenging superset of the pairwise > case; and we should still care about pairwise messaging. In the > pairwise case I think the main differentiator compared with TLS is the > requirement for asynchronicity; so if we're clearly carving up the > territory it might make sense to highlight this.> > Just my 2c though. I have no objection at all to changing the name, > and certainly agree that group support is a crucial aspect that could > be worth highlighting.> > > Jon > > On 24 Mar 2018, at 13:15, Shivan wrote: > >> +1 the name seems to be inspired by TLS but the drafts concern >> themselves explicitly with group messaging, not messaging as a whole.>> >> On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn Gillmor >> wrote:>>> Thanks for all the work that has gone into the proposed MLS >>> architecture>>> and protocol drafts already. >>> >>> As we move toward working group formation, i'm a little bit >>> concerned>>> that the ostensible name of the project ("message layer security")>>> doesn't adequately describe the most salient features. >>> >>> We spent most of the time at the BoF in IETF 101 London talking >>> about>>> the design of the group key agreement scheme and the strong >>> cryptographic properties we want it to provide -- and i >>> suspect that>>> most of the work in any formed WG will center around that problem.>>> >>> So it seems odd to me that the word "group" doesn't appear in >>> the name>>> "MLS". >>> >>> I'm no good at acronyms, but i'll just throw out two alternatives:>>> >>> MSG: Messaging Security for Groups >>> >>> MESSAGE: Message Encryption and Security Standard for >>> Asynchronous Group Environments>>> >>> I hope since the WG isn't yet formed, it's not too late to >>> consider a>>> change to the name. We ought to be up front about the group- >>> specific>>> context that we're talking about here, as we already have a >>> security>>> layer that works for messages passing between two endpoints >>> synchronously (TLS) and it'd be nice to clearly carve up the >>> territory.>>> >>> --dkg >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls[1] >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=q5KP1AJUu-4ir-39yrQWELe1gULZ7UQbevfDBrgr0ss&s=jlPCTk9fCDAvKt6l2DuFKYLJoRLEL_KXV7lPHhtlA3M&e=> _________________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls Links: 1. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=q5KP1AJUu-4ir-39yrQWELe1gULZ7UQbevfDBrgr0ss&s=jlPCTk9fCDAvKt6l2DuFKYLJoRLEL_KXV7lPHhtlA3M&e= --_----------=_152190033921141480 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
+1

I have no strong feelings regarding the name, but I do think we are working on groups because you need them for general messaging.

Katriel


On Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrote:
Thanks for raising this point. I'm also no good at naming, but agree that there's potential scope to name more clearly. A couple of points in response to the specific issues you raised though:

While most of the discussion has focused on groups, my feeling is that this is because group is a more challenging superset of the pairwise case; and we should still care about pairwise messaging. In the pairwise case I think the main differentiator compared with TLS is the requirement for asynchronicity; so if we're clearly carving up the territory it might make sense to highlight this.

Just my 2c though. I have no objection at all to changing the name, and certainly agree that group support is a crucial aspect that could be worth highlighting.


Jon

On 24 Mar 2018, at 13:15, Shivan <shivankaul.1993@gmail.com> wrote:

+1 the name seems to be inspired by TLS but the drafts concern themselves explicitly with group messaging, not messaging as a whole.  

On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Thanks for all the work that has gone into the proposed MLS architecture
and protocol drafts already.

As we move toward working group formation, i'm a little bit concerned
that the ostensible name of the project ("message layer security")
doesn't adequately describe the most salient features.

We spent most of the time at the BoF in IETF 101 London talking about
the design of the group key agreement scheme and the strong
cryptographic properties we want it to provide -- and i suspect that
most of the work in any formed WG will center around that problem.

So it seems odd to me that the word "group" doesn't appear in the name
"MLS".

I'm no good at acronyms, but i'll just throw out two alternatives:

  MSG: Messaging Security for Groups

  MESSAGE: Message Encryption and Security Standard for Asynchronous Group Environments

I hope since the WG isn't yet formed, it's not too late to consider a
change to the name.  We ought to be up front about the group-specific
context that we're talking about here, as we already have a security
layer that works for messages passing between two endpoints
synchronously (TLS) and it'd be nice to clearly carve up the territory.

        --dkg
_______________________________________________
MLS mailing list
_______________________________________________
MLS mailing list

--_----------=_152190033921141480-- From nobody Sat Mar 24 08:25:25 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3612D7E4 for ; Sat, 24 Mar 2018 08:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBN7N92kLJj9 for ; Sat, 24 Mar 2018 08:25:21 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1F3129C6A for ; Sat, 24 Mar 2018 08:25:20 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id e194so8332731wmd.3 for ; Sat, 24 Mar 2018 08:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=gnZh2m08amG5IPA5zBAcHHiwusx9sQ4qraUHDFSXt6s=; b=i3skwScvbBfBZreAJq8X5EOeDRvW+2E6fHZ2ISo5bqrDBauZLC2DPLyyAE4Yof35br Lno3nUP4vsg4RRAkMgrdclCi0HSSoi7tyJfoPaCYDtIeu07fsyChwYmyTBT6U4ueNtij Sil/fylrh2B1idI8x+B6f7rDOgE72MkOtp1UsHn6w87yPnZTjinbMJMgpKqTaFDKnKkb 5JISL6Stm+6V4AlARzEgEriHqOIklMRtSUYizUBTT3EKlyE5XQTwHy0RQh3TwUS+QXmP rEh/qlDE6abkXPAvg0A5JLOaEQj6+x2iTGWwifcbB9lJuW0+pgTdptvacyZg01ORW7gs hENw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=gnZh2m08amG5IPA5zBAcHHiwusx9sQ4qraUHDFSXt6s=; b=QRT+p2Vp8pUujS3RPuxM3W12K8yv/lB/9JpQCENPoX7LXfy5/TBTqsRQIMn0jPi3G5 K9MAhobpJPCigAdWtAE0HvaysE7xbC2iB+Wo2jPY1nJfgGhgNld3boKm384NHm3opMlJ 247IDMcaRWdzGKzh2hDIISAJBJEwmoqdCmUv+QNTT4We93Fgr0SrvsazwT3bH91mHsgV zaSKR9MgXG7xxgBV5P2Oc08/cn/e+y3fSRrIccMC+twRsas9h6LVs40FTRZnHL8h47aa qv3+pSUVlCRtHFTz02GvoyqQ8NM9MqNY4gZCFO4kAb1LrenpQmtP6obG8QzinrrFhjhh 8NYw== X-Gm-Message-State: AElRT7G/LPA3D4jGsLfXqegDgDHFDK+qNrkTuQNconlYmkXfKMLeAzeZ y8a0leAef8pN+yj/L/SYk4Hqu38KGsE= X-Google-Smtp-Source: AG47ELupZCL1jP6yIMgxgj6scLHjdy1HLAD97IFXO5xJeYyVyAJoYVwCL2poonLZHeBio4IHsI36Hg== X-Received: by 10.28.10.83 with SMTP id 80mr10624493wmk.70.1521905118665; Sat, 24 Mar 2018 08:25:18 -0700 (PDT) Received: from rmbp.fritz.box (HSI-KBW-078-043-029-194.hsi4.kabel-badenwuerttemberg.de. [78.43.29.194]) by smtp.gmail.com with ESMTPSA id i66sm16182799wmd.0.2018.03.24.08.25.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Mar 2018 08:25:17 -0700 (PDT) From: Raphael Robert Content-Type: multipart/alternative; boundary="Apple-Mail=_D5D83C89-A12E-407E-86FB-3FD8C949D38E" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 24 Mar 2018 16:25:16 +0100 References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> To: mls@ietf.org In-Reply-To: <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 15:25:24 -0000 --Apple-Mail=_D5D83C89-A12E-407E-86FB-3FD8C949D38E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We looked at a number of alternatives to MLS and in the end none of them = seemed to be substantially better than =E2=80=9CMessaging Layer = Security=E2=80=9D, but that doesn=E2=80=99t mean the name cannot be = changed. In my opinion =E2=80=9Cmessaging=E2=80=9D implies groups in 2018 and = it=E2=80=99s not a special case of messaging anymore. It's the norm for = non-E2EE products, and a number of E2EE messengers support it as well = already today: WhatsApp, Signal, Wire, etc. In the context of MLS, = =E2=80=9Cgroups" are also interchangeable with =E2=80=9Cmulti-device=E2=80= =9D, which is also becoming the norm. The 1:1 pairwise mode is still important technologically, but = application-wise it will most likely be perceived as a special case of = (group) messaging. Also just my 2c. Raphael > On 24 Mar 2018, at 15:05, Katriel Cohn-Gordon = wrote: >=20 > +1 >=20 > I have no strong feelings regarding the name, but I do think we are = working on groups because you need them for general messaging. >=20 > Katriel >=20 >=20 > On Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrote: >> Thanks for raising this point. I'm also no good at naming, but agree = that there's potential scope to name more clearly. A couple of points in = response to the specific issues you raised though: >>=20 >> While most of the discussion has focused on groups, my feeling is = that this is because group is a more challenging superset of the = pairwise case; and we should still care about pairwise messaging. In the = pairwise case I think the main differentiator compared with TLS is the = requirement for asynchronicity; so if we're clearly carving up the = territory it might make sense to highlight this. >>=20 >> Just my 2c though. I have no objection at all to changing the name, = and certainly agree that group support is a crucial aspect that could be = worth highlighting. >>=20 >>=20 >> Jon >>=20 >> On 24 Mar 2018, at 13:15, Shivan > wrote: >>=20 >>> +1 the name seems to be inspired by TLS but the drafts concern = themselves explicitly with group messaging, not messaging as a whole. =20= >>>=20 >>> On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn Gillmor = > wrote: >>> Thanks for all the work that has gone into the proposed MLS = architecture >>> and protocol drafts already. >>>=20 >>> As we move toward working group formation, i'm a little bit = concerned >>> that the ostensible name of the project ("message layer security") >>> doesn't adequately describe the most salient features. >>>=20 >>> We spent most of the time at the BoF in IETF 101 London talking = about >>> the design of the group key agreement scheme and the strong >>> cryptographic properties we want it to provide -- and i suspect that >>> most of the work in any formed WG will center around that problem. >>>=20 >>> So it seems odd to me that the word "group" doesn't appear in the = name >>> "MLS". >>>=20 >>> I'm no good at acronyms, but i'll just throw out two alternatives: >>>=20 >>> MSG: Messaging Security for Groups >>>=20 >>> MESSAGE: Message Encryption and Security Standard for Asynchronous = Group Environments >>>=20 >>> I hope since the WG isn't yet formed, it's not too late to consider = a >>> change to the name. We ought to be up front about the = group-specific >>> context that we're talking about here, as we already have a security >>> layer that works for messages passing between two endpoints >>> synchronously (TLS) and it'd be nice to clearly carve up the = territory. >>>=20 >>> --dkg >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls = >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvEq= Ma84Q&m=3Dq5KP1AJUu-4ir-39yrQWELe1gULZ7UQbevfDBrgr0ss&s=3DjlPCTk9fCDAvKt6l= 2DuFKYLJoRLEL_KXV7lPHhtlA3M&e=3D = >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls = >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls = --Apple-Mail=_D5D83C89-A12E-407E-86FB-3FD8C949D38E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = looked at a number of alternatives to MLS and in the end none of them = seemed to be substantially better than =E2=80=9CMessaging Layer = Security=E2=80=9D, but that doesn=E2=80=99t mean the name cannot be = changed.

In my = opinion =E2=80=9Cmessaging=E2=80=9D implies groups in 2018 and it=E2=80=99= s not a special case of messaging anymore. It's the norm for = non-E2EE products, and a number of E2EE messengers support it as well = already today: WhatsApp, Signal, Wire, etc. In the context of MLS, = =E2=80=9Cgroups" are also interchangeable with =E2=80=9Cmulti-device=E2=80= =9D, which is also becoming the norm.

The 1:1 pairwise mode is still = important technologically, but application-wise it will most likely be = perceived as a special case of (group) messaging.
Also just my 2c.

Raphael

On 24 Mar 2018, at 15:05, Katriel Cohn-Gordon <me@katriel.co.uk> = wrote:

+1

I= have no strong feelings regarding the name, but I do think we are = working on groups because you need them for general = messaging.

Katriel


On = Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrote:
Thanks for = raising this point. I'm also no good at naming, but agree that there's = potential scope to name more clearly. A couple of points in response to = the specific issues you raised though:

While most of the discussion has focused on groups, = my feeling is that this is because group is a more challenging superset = of the pairwise case; and we should still care about pairwise messaging. = In the pairwise case I think the main differentiator compared with TLS = is the requirement for asynchronicity; so if we're clearly carving up = the territory it might make sense to highlight this.

Just my 2c though. I = have no objection at all to changing the name, and certainly agree that = group support is a crucial aspect that could be worth highlighting.


Jon

On 24 Mar 2018, at 13:15, Shivan <shivankaul.1993@gmail.com> wrote:

+1 the name seems to be = inspired by TLS but the drafts concern themselves explicitly with group = messaging, not messaging as a whole.  

On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn = Gillmor <dkg@fifthhorseman.net> wrote:
Thanks for all the work that has gone into the proposed MLS = architecture
and protocol drafts already.

As= we move toward working group formation, i'm a little bit concerned
that the ostensible name of the project ("message layer = security")
doesn't adequately describe the most salient = features.

We spent most of the time at the BoF in IETF = 101 London talking about
the design of the group key agreement scheme = and the strong
cryptographic properties we want it to provide -- and = i suspect that
most of the work in any formed WG will center around = that problem.

So it seems odd to me that the word "group" = doesn't appear in the name
"MLS".

I'm no good at acronyms, but i'll just throw out two = alternatives:

  MSG: Messaging Security for Groups

  MESSAGE: Message Encryption and Security = Standard for Asynchronous Group Environments

I = hope since the WG isn't yet formed, it's not too late to consider a
change to the name.  We ought to be up front about the = group-specific
context that we're talking about here, as we already = have a security
layer that works for messages passing between two = endpoints
synchronously (TLS) and it'd be nice to clearly carve = up the territory.

      =   --dkg
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
_______________________________________________
MLS mailing list
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&am= p;r=3DM0CVEJydBVUX_bvEqMa84Q&m=3Dq5KP1AJUu-4ir-39yrQWELe1gULZ7UQbevfDB= rgr0ss&s=3DjlPCTk9fCDAvKt6l2DuFKYLJoRLEL_KXV7lPHhtlA3M&e=3D
_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

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

= --Apple-Mail=_D5D83C89-A12E-407E-86FB-3FD8C949D38E-- From nobody Sat Mar 24 08:31:50 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB884129C59 for ; Sat, 24 Mar 2018 08:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUA-q5-7JsOo for ; Sat, 24 Mar 2018 08:31:46 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 E99021201F2 for ; Sat, 24 Mar 2018 08:31:45 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id u200so8944805vke.4 for ; Sat, 24 Mar 2018 08:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9JJ7R+tLX3GZCO1e2j/4y9O9viAQoLSdfIIoH4t08mw=; b=SxkYpAxyZUlgz7Vn+mlJUbSJl+mYpBDC1ESeI01rNz1lvEAPl/o1ucO6s2vDpBD2y7 0JN7l2fdWCsSgDr/duIrcEISt6s2xoN9/QBaUbQJfhKIdWEWVC9OXeoysupoQeSSCulD YEnWaKBKJYH+xK6JWgSTDtWUbOhfSNqaViSbZQy4EChpbvH8s927BfTmew3R72DWKW6c hU8dvMWOFPW5d4xH9++mkLtxSf0Aei6l2pWVvygaYpearAgHi4hqy7tGw1RHPRPfLO7u ztBpKWXRDOBhe88jKBeVg/vpKn9+p8U1SQLF/R9T7ZYGoWowxVKowx7PMxxmeuVrQojz OS4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9JJ7R+tLX3GZCO1e2j/4y9O9viAQoLSdfIIoH4t08mw=; b=UKR4WkZZ+JAjpDlU3xry+XkZc4e6VTLqduFOf1MEU0a41KGLQFNsidYuD9RZWJuk/+ dsnAHWRCU+UODbKVkmQmcafOPq2/js4mcTOrOvc/GiNn6FeeIoTSK5qhcglDuLjQGuUR mt79Q7xJhb2cpmTizWSzxDcpyYKDJHPcUyk8OFo6SIBb9yg8RZN3IHahMd3oVuIgyWYK t7BFZX5ZTFQ0HLm4X1GBOMaGPvVBC1BeUB7VP0/mSlunAFmIftJz++vuPhxe7QNrM7j5 zm2LqFN0HqAQyjvAxGxehdmWB6C2yglLnHMuv2ZYbrHHgkA0Ep8N0sZcA0TSirwuJOYI nh+g== X-Gm-Message-State: AElRT7FasX0yIAtKjZdq3+pVDl1LF8VfV42ZywvfyHE3rHeHzDOlkZEf 1earc4YqvEfN1b0YSdO67jcDW1OlV7h32aKfa6c= X-Google-Smtp-Source: AG47ELsORqmUL8fYQxs8dmqUsBymko29xsem67b9Top+mKFRAHprmuTBC1np3TfxPbX//Q1Z5Bp9ttZQLnJesSJFU1Q= X-Received: by 10.31.174.80 with SMTP id x77mr17906459vke.101.1521905504840; Sat, 24 Mar 2018 08:31:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.32.67 with HTTP; Sat, 24 Mar 2018 08:31:44 -0700 (PDT) In-Reply-To: References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> From: Suhas Nandakumar Date: Sat, 24 Mar 2018 08:31:44 -0700 Message-ID: To: Raphael Robert Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a1143fa3aff71f505682a3c60" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 15:31:49 -0000 --001a1143fa3aff71f505682a3c60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 'mls' seems to be a fine name as it indicates e2e security for messaging layer of the stack. Group vs 1:1 is a realization of an application context on top of such a abstraction layer is what i feel. ./S On Sat, Mar 24, 2018 at 8:25 AM, Raphael Robert wrote: > We looked at a number of alternatives to MLS and in the end none of them > seemed to be substantially better than =E2=80=9CMessaging Layer Security= =E2=80=9D, but that > doesn=E2=80=99t mean the name cannot be changed. > > In my opinion =E2=80=9Cmessaging=E2=80=9D implies groups in 2018 and it= =E2=80=99s not a special > case of messaging anymore. It's the norm for non-E2EE products, and a > number of E2EE messengers support it as well already today: WhatsApp, > Signal, Wire, etc. In the context of MLS, =E2=80=9Cgroups" are also inter= changeable > with =E2=80=9Cmulti-device=E2=80=9D, which is also becoming the norm. > > The 1:1 pairwise mode is still important technologically, but > application-wise it will most likely be perceived as a special case of > (group) messaging. > > Also just my 2c. > > Raphael > > On 24 Mar 2018, at 15:05, Katriel Cohn-Gordon wrote: > > +1 > > I have no strong feelings regarding the name, but I do think we are > working on groups *because* you need them for general messaging. > > Katriel > > > On Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrote: > > Thanks for raising this point. I'm also no good at naming, but agree that > there's potential scope to name more clearly. A couple of points in > response to the specific issues you raised though: > > While most of the discussion has focused on groups, my feeling is that > this is because group is a more challenging superset of the pairwise case= ; > and we should still care about pairwise messaging. In the pairwise case I > think the main differentiator compared with TLS is the requirement for > asynchronicity; so if we're clearly carving up the territory it might mak= e > sense to highlight this. > > Just my 2c though. I have no objection at all to changing the name, and > certainly agree that group support is a crucial aspect that could be wort= h > highlighting. > > > Jon > > On 24 Mar 2018, at 13:15, Shivan wrote: > > +1 the name seems to be inspired by TLS but the drafts concern themselves > explicitly with group messaging, not messaging as a whole. > > On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn Gillmor > wrote: > > Thanks for all the work that has gone into the proposed MLS architecture > and protocol drafts already. > > As we move toward working group formation, i'm a little bit concerned > that the ostensible name of the project ("message layer security") > doesn't adequately describe the most salient features. > > We spent most of the time at the BoF in IETF 101 London talking about > the design of the group key agreement scheme and the strong > cryptographic properties we want it to provide -- and i suspect that > most of the work in any formed WG will center around that problem. > > So it seems odd to me that the word "group" doesn't appear in the name > "MLS". > > I'm no good at acronyms, but i'll just throw out two alternatives: > > MSG: Messaging Security for Groups > > MESSAGE: Message Encryption and Security Standard for Asynchronous Grou= p > Environments > > I hope since the WG isn't yet formed, it's not too late to consider a > change to the name. We ought to be up front about the group-specific > context that we're talking about here, as we already have a security > layer that works for messages passing between two endpoints > synchronously (TLS) and it'd be nice to clearly carve up the territory. > > --dkg > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf..org_mailman_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3D > M0CVEJydBVUX_bvEqMa84Q&m=3Dq5KP1AJUu-4ir-39yrQWELe1gULZ7UQbevfDBrgr0ss&s= =3D > jlPCTk9fCDAvKt6l2DuFKYLJoRLEL_KXV7lPHhtlA3M&e=3D > > > *_______________________________________________* > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --001a1143fa3aff71f505682a3c60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
'mls' seems to be a fine name as it indicates e2e = security for messaging layer of the stack. Group vs 1:1 is a realization of= an application context on top of such a abstraction layer is what i feel.<= div>
./S



On Sat, Mar 24, 2018 at = 8:25 AM, Raphael Robert <raphael@wire.com> wrote:
We looked at a number of alternatives to MLS and in the end no= ne of them seemed to be substantially better than =E2=80=9CMessaging Layer = Security=E2=80=9D, but that doesn=E2=80=99t mean the name cannot be changed= .

In my opinion =E2=80=9Cmessaging=E2=80=9D implies grou= ps in 2018 and it=E2=80=99s not a special case of messaging anymore.=C2=A0I= t's the norm for non-E2EE products, and a number of E2EE messengers sup= port it as well already today: WhatsApp, Signal, Wire, etc. In the context = of MLS, =E2=80=9Cgroups" are also interchangeable with =E2=80=9Cmulti-= device=E2=80=9D, which is also becoming the norm.

= The 1:1 pairwise mode is still important technologically, but application-w= ise it will most likely be perceived as a special case of (group) messaging= .

Also just my 2c.

Raphae= l

On= 24 Mar 2018, at 15:05, Katriel Cohn-Gordon <me@katriel.co.uk> wrote:

=
+1

I have no strong feelin= gs regarding the name, but I do think we are working on groups=C2=A0because=C2=A0y= ou need them for general messaging.

Katriel
<= /div>


On Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrot= e:
Th= anks for raising this point. I'm also no good at naming, but agree that= there's potential scope to name more clearly. A couple of points in re= sponse to the specific issues you raised though:

While most of the discussion has foc= used on groups, my feeling is that this is because group is a more challeng= ing superset of the pairwise case; and we should still care about pairwise = messaging. In the pairwise case I think the main differentiator compared wi= th TLS is the requirement for asynchronicity; so if we're clearly carvi= ng up the territory it might make sense to highlight this.
Just my 2c though. I have no objection at all to changing the= name, and certainly agree that group support is a crucial aspect that coul= d be worth highlighting.
=

Jon

On 24 Mar= 2018, at 13:15, Shivan <shivankaul.1993@gmail.com> wrote:

<= div>
+1 the name seems to be inspired by TLS but the drafts concern the= mselves explicitly with group messaging, not messaging as a whole.=C2=A0=C2= =A0


<= div style=3D"font-family:georgia,serif">So it seems odd to me that the word= "group" doesn't appear in the name

______________________________= _________________
MLS mailing list
<= a href=3D"https://www.ietf.org/mailman/listinfo/mls" target=3D"_blank">http= s://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


--001a1143fa3aff71f505682a3c60-- From nobody Sat Mar 24 15:33:06 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E81126DC2 for ; Sat, 24 Mar 2018 15:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srVJF-oxMXka for ; Sat, 24 Mar 2018 15:33:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8049212025C for ; Sat, 24 Mar 2018 15:33:03 -0700 (PDT) Received: from fifthhorseman.net (unknown [192.54.222.4]) by che.mayfirst.org (Postfix) with ESMTPSA id B7562F99A for ; Sat, 24 Mar 2018 18:33:02 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id C5AE02066D; Sat, 24 Mar 2018 22:32:49 +0000 (GMT) From: Daniel Kahn Gillmor To: mls@ietf.org Date: Sat, 24 Mar 2018 18:32:46 -0400 Message-ID: <87efk9m7e9.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 22:33:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable In the BoF at IETF 101, I expressed my concern about the way that multiple devices fits in the architectural requirements. I'm repeating those concerns on-list here in the hopes of raising on-list discussion, and trying to flesh them out here in more detail. I see two use cases that might come under the "multi-device" rubric: a) device loss/recovery b) actual concurrent use (e.g. laptop + desktop + mobile) i'll focus here mainly on (b), since i think (a) is a distinct situation. Privacy Considerations =2D--------------------- It's not clear to me that any user has a situation where they *want* to indicate to other users of the group which device they're using. I also think that even in some situations where facts about device usage are being published with some sort of opt-in consent, the privacy implications are not well-understood by the users. (e.g. https://www.cnet.com/news/trumps-tweets-android-for-nasty-iphone-for-= nice/) At any rate, a user who wants to let other participants know "i'm now at home on the couch using my BananaTV" or even "this morning i'm using the device that i usually only use in the evenings" can do so at the application layer (i.e. in an explicit message to the other participants). The number of devices a user controls might itself be sensitive to the user (e.g. a higher risk of device theft, or inference about the user's behavior patterns) Security Considerations =2D---------------------- When the user has multiple devices, there are two possible approaches: 0) sharing decryption-capable keys across devices (peers see a single key for each user) 1) distinct per-device decryption-capable keys (peers see multiple keys per user) One potential argument is that option (1) might provide "transparency" -- or visibility of a key change in the event of an adversary who tries to change the keys of a client. but i don't think this argument works. At the BoF it was clear that even if the design assumes (1), it's possible for systems to implement (0) if they want to hide the number of devices (or if they're adversarial and have compromised an endpoint). So there isn't a clear security-through-transparency argument. Furthermore, it's not clear what a group conversation participant can *do*, security-wise, in the event of recieving such a message from another participant -- is this actually a new phone, or is it a wiretap injection? should i ask the user about it? should i take action? what ction? To avoid UX warning fatigue, i'm wary about introducing more of these events than are strictly necessary (scenario (a) above probably represents a "necessary" event, sadly, but "i just got a new phone" doesn't seem necessary). And finally, we presumably want any sort of device change to be authorized from an already-known device for the same user. So when the user gains an additional device, we need *some* form of communication between the new device and an old device. That interaction could be a confirmation-signature action (case 1), or it could be a private-key-sharing interaction (case 0). Single-key-per-participant seems better =2D-------------------------------------- So exposing the presence of multiple devices to the other participants seems strictly worse from a privacy perspective, and it may facilitate unnoticed wiretap-style extra-key-injection (due to concerns about warning fatigue). Wouldn't it be safer and simpler to assume a design that insists on single-key-per-user, and hide multi-device private-key-synchronization from the other participants in the group chat? i wouldn't object to specifying a mechanism for private-key synchronization between devices held by the same user; but i worry about exposing multiple-keys-per-user to the messaging group itself. it may make the protocol worse in terms of privacy, usability, and security. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCWrbSDgAKCRBsHx7ezFD6 UwecAP9ys7WKj6+IMRjXm/Neup5GEA7N0kgRZuTb26Oc5IDWXgEAooB9XCNV4M5L +aHyiHaTOI3afhLsgHin82QGYRszUw8= =6Ai9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 24 15:43:24 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A533B126DC2 for ; Sat, 24 Mar 2018 15:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc1o5ohtZYGj for ; Sat, 24 Mar 2018 15:43:20 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53AC12025C for ; Sat, 24 Mar 2018 15:43:20 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id c3-v6so13191552oib.5 for ; Sat, 24 Mar 2018 15:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fzw7yuWOy6NqmOSfmafoQ/oHVvFimDfQuFVADtwPgUQ=; b=MkhrGrM3VF837R1p8Xdkurgn5z5ym9L58kC0Khq/V1VeFIEj7tNNl1MjkwBmnNSVbq OXZZJSOlKXu3JeYb/H3V+rIdXUhKE8wfXajWNeD794hNtRprlQR6AYyqOKTMAo16lEmZ FvsB8TA5En8NXnwBkdVbTAiQKnzpDA2FWQgcoBEFm+7u6VDQPx+1iY7N2iY7c9s8Adnw lEw3Ee8Q+j9LC0uDJgTnmNj1aqkft4z+tJzYp+VsLad/0vZZ/FfEVMlsG7GV+XROYXr9 dTj1Phb3zaQ7YgNBf2LKkx7gnW5Iz96DIQUs65hSLH0vrEahp6mMaLZAd3HgNqNdxJW3 83vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fzw7yuWOy6NqmOSfmafoQ/oHVvFimDfQuFVADtwPgUQ=; b=eibYGlMcPebdPAXF8L+0r55wLk7IeQvvmD1b92OTvZlm+LkIO25f2KqvHAUyPOIai9 XhJKmWBt0kmb1+qHOLGhXXN67MyaTJbtm6H21A3+mYhp6+hejuNItzF021ytYusn+E/L H1kcNamY+O4p0qwK5qo4Y+ClmG6RC3yrvefF7ck3CnmiPkvPcnfcsrOqmOmcUFW8QdAO jgAxZDevUI3pw6nWFL/kF6sOy/CMLgiIOX82yBt7i+GMTtYDBEiFkYJo3X2714AFjVfu b8+tbW6n3YWH2OxXzXd0qaGFa59AAJ67l4xPjiaIimVD3sr4WAPwC47jn3kdFIGAUAY8 znVQ== X-Gm-Message-State: AElRT7GQS167gmcXra5rBIbLiw+ewtebcvKu8k0OIFFs0JThh27ymvB8 W+d9yOmoYnzOhf20eRh3y9seKRhnoeDS+xFDhyCLlw== X-Google-Smtp-Source: AG47ELsl39m3TSOYPu/9mgfvlluvPbwt0iwGlFndwDSNoNSiedxsTA2xGfB9FzNhXyFWBJtRV3vOUADlof77xCQuYLU= X-Received: by 10.202.84.75 with SMTP id i72mr20127800oib.262.1521931399916; Sat, 24 Mar 2018 15:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.23.21 with HTTP; Sat, 24 Mar 2018 15:42:39 -0700 (PDT) In-Reply-To: <87efk9m7e9.fsf@fifthhorseman.net> References: <87efk9m7e9.fsf@fifthhorseman.net> From: Eric Rescorla Date: Sat, 24 Mar 2018 22:42:39 +0000 Message-ID: To: Daniel Kahn Gillmor Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="001a113ac71476feb60568304434" Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 22:43:23 -0000 --001a113ac71476feb60568304434 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor wrote: > In the BoF at IETF 101, I expressed my concern about the way that > multiple devices fits in the architectural requirements. I'm repeating > those concerns on-list here in the hopes of raising on-list discussion, > and trying to flesh them out here in more detail. > > I see two use cases that might come under the "multi-device" rubric: > > a) device loss/recovery > > b) actual concurrent use (e.g. laptop + desktop + mobile) > > i'll focus here mainly on (b), since i think (a) is a distinct > situation. > > Privacy Considerations > ---------------------- > > It's not clear to me that any user has a situation where they *want* to > indicate to other users of the group which device they're using. Really? Because this kind of status reporting is actually a reasonably common feature of IM systems. Security Considerations > ----------------------- > > When the user has multiple devices, there are two possible approaches: > > 0) sharing decryption-capable keys across devices (peers see a single > key for each user) > > 1) distinct per-device decryption-capable keys (peers see multiple keys > per user) > > One potential argument is that option (1) might provide > "transparency" -- or visibility of a key change in the event of an > adversary who tries to change the keys of a client. but i don't think > this argument works. > The reason for #1 isn't transparency, it's that there are use cases in which users want to add a new device without an existing device being online, and these are incompatible with type #0 designs. Furthermore, it's not clear what a group conversation participant can > *do*, security-wise, in the event of recieving such a message from > another participant -- is this actually a new phone, or is it a wiretap > injection? should i ask the user about it? should i take action? what > ction? > Generally, I wouldn't expect them to take any action at all. It's a user's responsibility to ensure that the right number of devices are registered to their account, just as its common for the number of Web browsers one has attached to ones Gmail account. > To avoid UX warning fatigue, i'm wary about introducing more of these > events than are strictly necessary (scenario (a) above probably > represents a "necessary" event, sadly, but "i just got a new phone" > doesn't seem necessary). > > And finally, we presumably want any sort of device change to be > authorized from an already-known device for the same user. This was not in fact my assumption, for the reason indicated above -Ekr > > --001a113ac71476feb60568304434 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor <dkg@fifthho= rseman.net> wrote:
In the B= oF at IETF 101, I expressed my concern about the way that
multiple devices fits in the architectural requirements.=C2=A0 I'm repe= ating
those concerns on-list here in the hopes of raising on-list discussion,
and trying to flesh them out here in more detail.

I see two use cases that might come under the "multi-device" rubr= ic:

=C2=A0a) device loss/recovery

=C2=A0b) actual concurrent use (e.g. laptop + desktop + mobile)

i'll focus here mainly on (b), since i think (a) is a distinct
situation.

Privacy Considerations
----------------------

It's not clear to me that any user has a situation where they *want* to=
indicate to other users of the group which device they're using.=C2=A0<= /blockquote>

Really? Because this kind of status reporti= ng is actually a reasonably common
feature of IM systems.


Security Considerations
-----------------------

When the user has multiple devices, there are two possible approaches:

=C2=A00) sharing decryption-capable keys across devices (peers see a single=
=C2=A0 =C2=A0 key for each user)

=C2=A01) distinct per-device decryption-capable keys (peers see multiple ke= ys
=C2=A0 =C2=A0 per user)

One potential argument is that option (1) might provide
"transparency" -- or visibility of a key change in the event of a= n
adversary who tries to change the keys of a client.=C2=A0 but i don't t= hink
this argument works.

The reason for #1 = isn't transparency, it's that there are use cases in
whic= h users want to add a new device without an existing device being
online, and these are incompatible with type #0 designs.



Furthermore, it's not clear what a group conversation participant can *do*, security-wise, in the event of recieving such a message from
another participant -- is this actually a new phone, or is it a wiretap
injection?=C2=A0 should i ask the user about it?=C2=A0 should i take action= ?=C2=A0 what
ction?

Generally, I wouldn't expect= them to take any action at all. It's a user's
responsibi= lity to ensure that the right number of devices are registered
to= their account, just as its common for the number of Web browsers
one has attached to ones Gmail account.


To avoid UX warning fatigue, i'm wary about introducing more of these events than are strictly necessary (scenario (a) above probably
represents a "necessary" event, sadly, but "i just got a new= phone"
doesn't seem necessary).

And finally, we presumably want any sort of device change to be
authorized from an already-known device for the same user.=C2=A0

This was not in fact my assumption, for the reason i= ndicated above

-Ekr

--001a113ac71476feb60568304434-- From nobody Sat Mar 24 15:53:05 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626841241F5 for ; Sat, 24 Mar 2018 15:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vV-weteXBt-f for ; Sat, 24 Mar 2018 15:53:01 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBA612025C for ; Sat, 24 Mar 2018 15:53:00 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id j85so9273184vke.0 for ; Sat, 24 Mar 2018 15:53:00 -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=uuRmC4wbBAj/ABlBIr21uKHHVrN0/gmlVnDu+XcOmrA=; b=GM6Wn9uxTDCPP5YCjTsnypwqkqsptrPz4ln/XbaRUJqUBuGZJDR1YFr2lNBPBetTvY dKoBRjEAkD3XtTuUtUS6R9jjyllUaBS5DdS8enVeIPqNfVl2zqgKTfA6yCjSUnhPZk1I k/mejUFiuqn5Czp9v3hS4C0QtOQL2ITDUjv+sb2ky+p8FCha8B3DLdtVU+1OeBEJf8vo ukLjNBaUeWMLwt81fV7tHkgWsgM+BEJxAE7y2cu/nfVTpzdfqLL8N0sdAeDRFUHUDpv9 tZ4vV5Mi3JQx35ff/0/pG3bgbIVJ7vsLqVh7kb+nQl8sY1F+MGIffv0526lxe4EYxUYR 5XKw== 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=uuRmC4wbBAj/ABlBIr21uKHHVrN0/gmlVnDu+XcOmrA=; b=Skk8ao6/SMBVwdxpffiRrhO4QqHOQSHg0kVSBqJUktJh92rYut0/gVGICUL3unilBK 6HwZFAMETiykiYMXnwmBZ6vg/y/mSgYzWnYyzuPA9zER0tVqaKtnrvhJLJWOCcypbTXE pxtGWCzHKfcNGy0XQQ3zbCE/wVYlHKOqGhuNKcMb6sDJzNIRMiU44PshpC7kxmppRhvR fHwf5VX7w7fYjY1A1y+uH4LNiBQxmidfr9CatoCA1FH8hLMR7fifPJMQo6dyQKrxKIUR ZsjJ376Hshxx5sqBt9PgnPJZT2ItA5FIsogzyAZD3X2+lxo0+/4/SdKbribpCEdR6Lss 4K9w== X-Gm-Message-State: AElRT7G3zlBWYGhwtTxlkrjZx54udXrldkujvV+K3ULbfOdfCGwIM+kS 7av8rrhxnqUFLiWGIdSzxTLxi4L4buJXkN4CwC4rAg== X-Google-Smtp-Source: AG47ELtP+TVla5tLjH2KfIeReSYLqH5kzkGjOueCSOEqjyzHKwNjSO5byKjmt70LUImIdfZydjRVBDOP8aWc1H2VP6k= X-Received: by 10.31.231.5 with SMTP id e5mr21115112vkh.39.1521931979475; Sat, 24 Mar 2018 15:52:59 -0700 (PDT) MIME-Version: 1.0 References: <87efk9m7e9.fsf@fifthhorseman.net> In-Reply-To: From: Justin Uberti Date: Sat, 24 Mar 2018 22:52:48 +0000 Message-ID: To: Eric Rescorla Cc: dkg@fifthhorseman.net, mls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c094c3202f6370568306740" Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 22:53:03 -0000 --94eb2c094c3202f6370568306740 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 24, 2018 at 3:43 PM Eric Rescorla wrote: > > > On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor < > dkg@fifthhorseman.net> wrote: > >> In the BoF at IETF 101, I expressed my concern about the way that >> multiple devices fits in the architectural requirements. I'm repeating >> those concerns on-list here in the hopes of raising on-list discussion, >> and trying to flesh them out here in more detail. >> >> I see two use cases that might come under the "multi-device" rubric: >> >> a) device loss/recovery >> >> b) actual concurrent use (e.g. laptop + desktop + mobile) >> >> i'll focus here mainly on (b), since i think (a) is a distinct >> situation. >> >> Privacy Considerations >> ---------------------- >> >> It's not clear to me that any user has a situation where they *want* to >> indicate to other users of the group which device they're using. > > > Really? Because this kind of status reporting is actually a reasonably > common > feature of IM systems. > > > Security Considerations >> ----------------------- >> >> When the user has multiple devices, there are two possible approaches: >> >> 0) sharing decryption-capable keys across devices (peers see a single >> key for each user) >> >> 1) distinct per-device decryption-capable keys (peers see multiple keys >> per user) >> >> One potential argument is that option (1) might provide >> "transparency" -- or visibility of a key change in the event of an >> adversary who tries to change the keys of a client. but i don't think >> this argument works. >> > > The reason for #1 isn't transparency, it's that there are use cases in > which users want to add a new device without an existing device being > online, and these are incompatible with type #0 designs. > Also, allowing exfiltration of keys in order to allow cross-device sharing seems to introduce its own set of problems. > > > > Furthermore, it's not clear what a group conversation participant can >> *do*, security-wise, in the event of recieving such a message from >> another participant -- is this actually a new phone, or is it a wiretap >> injection? should i ask the user about it? should i take action? what >> ction? >> > > Generally, I wouldn't expect them to take any action at all. It's a user's > responsibility to ensure that the right number of devices are registered > to their account, just as its common for the number of Web browsers > one has attached to ones Gmail account. > > >> To avoid UX warning fatigue, i'm wary about introducing more of these >> events than are strictly necessary (scenario (a) above probably >> represents a "necessary" event, sadly, but "i just got a new phone" >> doesn't seem necessary). >> >> And finally, we presumably want any sort of device change to be >> authorized from an already-known device for the same user. > > > This was not in fact my assumption, for the reason indicated above > > -Ekr > >> >> _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --94eb2c094c3202f6370568306740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On= Sat, Mar 24, 2018 at 3:43 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor &= lt;dkg@fifthhors= eman.net> wrote:
In the B= oF at IETF 101, I expressed my concern about the way that
multiple devices fits in the architectural requirements.=C2=A0 I'm repe= ating
those concerns on-list here in the hopes of raising on-list discussion,
and trying to flesh them out here in more detail.

I see two use cases that might come under the "multi-device" rubr= ic:

=C2=A0a) device loss/recovery

=C2=A0b) actual concurrent use (e.g. laptop + desktop + mobile)

i'll focus here mainly on (b), since i think (a) is a distinct
situation.

Privacy Considerations
----------------------

It's not clear to me that any user has a situation where they *want* to=
indicate to other users of the group which device they're using.=C2=A0<= /blockquote>

Really? Because this kind of status reporti= ng is actually a reasonably common
feature of IM systems.


Security Considerations
-----------------------

When the user has multiple devices, there are two possible approaches:

=C2=A00) sharing decryption-capable keys across devices (peers see a single=
=C2=A0 =C2=A0 key for each user)

=C2=A01) distinct per-device decryption-capable keys (peers see multiple ke= ys
=C2=A0 =C2=A0 per user)

One potential argument is that option (1) might provide
"transparency" -- or visibility of a key change in the event of a= n
adversary who tries to change the keys of a client.=C2=A0 but i don't t= hink
this argument works.

The reason for #1 = isn't transparency, it's that there are use cases in
whic= h users want to add a new device without an existing device being
online, and these are incompatible with type #0 designs.
=

Also, allowing exfiltration of keys = in order to allow cross-device sharing seems to introduce its own set of pr= oblems.=C2=A0



Furthermore, it's not clear what a group conversation participant can *do*, security-wise, in the event of recieving such a message from
another participant -- is this actually a new phone, or is it a wiretap
injection?=C2=A0 should i ask the user about it?=C2=A0 should i take action= ?=C2=A0 what
ction?

Generally, I wouldn't expect= them to take any action at all. It's a user's
responsibi= lity to ensure that the right number of devices are registered
to= their account, just as its common for the number of Web browsers
one has attached to ones Gmail account.


To avoid UX warning fatigue, i'm wary about introducing more of these events than are strictly necessary (scenario (a) above probably
represents a "necessary" event, sadly, but "i just got a new= phone"
doesn't seem necessary).

And finally, we presumably want any sort of device change to be
authorized from an already-known device for the same user.=C2=A0

This was not in fact my assumption, for the reason i= ndicated above

-Ekr

_______________________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls
--94eb2c094c3202f6370568306740-- From nobody Sat Mar 24 16:08:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA812025C for ; Sat, 24 Mar 2018 16:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=URtYwRL5; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=eWkdyaT/ 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 fTTV1BgqcDul for ; Sat, 24 Mar 2018 16:08:44 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DEC126DCA for ; Sat, 24 Mar 2018 16:08:44 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2ON8EmW003895; Sat, 24 Mar 2018 16:08:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=y4+UABTsyY6tSThQX+2Qa+99BGawdIIXBg65KPHKe58=; b=URtYwRL5+cCZBh4SSZdQtFrlbLaYp1VVFjSmXw+KWcwKZmxF+uL0+2zzgbm+j/9aQp9l oR6bHHiEPGZMwTlxi17ZlwmsYIym8NUNIGOvvWU9bCdzhip7Ni20+T/IAE9UNg0t2b86 EXcoNsGWs7C+7AOrjyQQDRXUSW5nKjFB9XU= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2gwmh58wck-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2018 16:08:42 -0700 Received: from PRN-CHUB02.TheFacebook.com (2620:10d:c081:35::11) by PRN-CHUB03.TheFacebook.com (2620:10d:c081:35::12) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 16:08:41 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.12) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 16:08:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y4+UABTsyY6tSThQX+2Qa+99BGawdIIXBg65KPHKe58=; b=eWkdyaT/8bq0wEuUwQDpY/D3hrphXdpohYqB0UL1/oW0KFU0GEeKjpxG12uXRZYzCz32HTYi7j0YxskehfUqqdPlQ1+rPj8FiUxXWztWIt5lxKVjhT5w2Ef0NmRknAb2GBbsBFVrSGT/GsrjpHIpkWsw5fs1FU2Abv/QfpT7gh8= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1847.namprd15.prod.outlook.com (10.174.54.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sat, 24 Mar 2018 23:08:39 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0609.012; Sat, 24 Mar 2018 23:08:39 +0000 From: Jon Millican To: Eric Rescorla , Daniel Kahn Gillmor CC: "mls@ietf.org" Thread-Topic: [MLS] multiple devices per user? Thread-Index: AQHTw8Ae2CgUeIFvK0mYODDXyt5r4qPf+1KAgAAHQoA= Date: Sat, 24 Mar 2018 23:08:39 +0000 Message-ID: <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> References: <87efk9m7e9.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.39.102.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1847; 7:77NSAK4NYYLjGvsbh+W3KX0v9UGb33RLaqd3o5yn2ACfAQpe7k39jig5U+CwA1ICm6UCBXUMaTOZ8l1op1V69M+KVA9rgBYe4kWCDsgohg7MaqubDME0B0sI94hw1l9w1WSjneJ5t0FD9muUcWu3MzFy0RRS0g/Isy9T95x9d+j4HRpjVF/3A/GA+VS8rsi67dzRBASxZ/SX8avSPqMv0PtgfajjUSwlEwLGGEb31u60tAU7UQnavonbwSLNCTMs; 20:zrAtde6TulGGmIzs9Soo+bVNl44ZFyKJUPDjdOlks94mZrqTqgddrViXahFQjNTntOel02HFT93PogU99GKf+r3cxniA28QcGGy/RYJtQJhfKC5BBE6j2sdtOXYUzyXfaAG9jrpJ2sT9txta1vUZL0ORxdAHnNE35qRppil/lkI= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 281ecc80-bb56-4ac2-8d69-08d591dc2e1f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1847; x-ms-traffictypediagnostic: CY4PR15MB1847: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(209352067349851)(192374486261705)(81227570615382)(21748063052155)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR15MB1847; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1847; x-forefront-prvs: 0621E7E436 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(396003)(39380400002)(346002)(199004)(189003)(97736004)(6436002)(6486002)(8676002)(186003)(236005)(6512007)(6306002)(54896002)(81156014)(68736007)(53936002)(5250100002)(86362001)(6246003)(5890100001)(102836004)(55236004)(76176011)(53546011)(83716003)(59450400001)(316002)(478600001)(26005)(8936002)(81166006)(33656002)(229853002)(446003)(14454004)(4326008)(2900100001)(2906002)(3846002)(6116002)(99286004)(110136005)(6506007)(25786009)(36756003)(82746002)(5660300001)(105586002)(7736002)(66066001)(3280700002)(11346002)(106356001)(3660700001)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1847; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rt7RSxcBLWB2dNEcRrHJ/YK2MV6DBpZl+0VUnh/Xz8NctGhFuq8ukXGIsnS8G+viNI5Alfaqlq1gGHUFuiWb+f58JrSJDkWQeY7P5ptUgesO7u/naFCOkvItIDK/CoiI3HFJK4zQYMCZuFwZGFJP7PimHH+sWtTYGdRBYSXeT+50K1Day8GsYTTz4gp0SoHeSS4k6iF6DdLu2zhjd2SWhnHy86IrVP8bOxbFgUxlmlp9COf9g11500i3ALT5kghAG6IVsfxrHb0YfiXfNBtkAgugbH0h3oMVTG/0VJrfa/bteaIogxY2le/TCXmeDHy4Tnx99xx/OySOJTLxIOCTFA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_02DC72FA0C574A1B920D4B456121CC55fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 281ecc80-bb56-4ac2-8d69-08d591dc2e1f X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2018 23:08:39.4820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1847 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-24_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 23:08:47 -0000 --_000_02DC72FA0C574A1B920D4B456121CC55fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgbGlrZSB0byBzZWNvbmQgRWty4oCZcyBwb2ludHMgaGVyZS4gVG8gcHJvdmlkZSBhIGNv bmNyZXRlIHVzZSBjYXNlLCBpbiBGYWNlYm9vayBNZXNzZW5nZXIsIHdlIHdhbnQgU2VjcmV0IENv bnZlcnNhdGlvbnMgdG8gd29yayBmb3IgYSB1c2VyIGFzIHNvb24gYXMgdGhleSBsb2cgaW4gb24g YSBuZXcgZGV2aWNlLiBUaGlzIHNvbWV3aGF0IGJsdXJzIHRoZSBib3VuZGFyeSBiZXR3ZWVuIGRl dmljZSBsb3NzL3JlY292ZXJ5IGFuZCBjb25jdXJyZW50IHVzZSBhcyBpdCBpcyB1c2VkIGZvciBi b3RoIHNpdHVhdGlvbnM7IGJ1dCB3ZSBkb27igJl0IHdhbnQgdG8gcmVxdWlyZSBleGlzdGluZyBk ZXZpY2UgdG8gYXV0aG9yaXNlIG5ldyBkZXZpY2VzIGFzIOKAkyB0byBiZSBwZXJmZWN0bHkgZnJh bmsg4oCTIHdl4oCZcmUgbm90IGNvbnZpbmNlZCB0aGF0IG1vc3QgcGVvcGxlIHdvdWxkIGFjdHVh bGx5IGRvIHRoaXMsIGFuZCBpdCBwdXRzIGEgcG90ZW50aWFsIHVzYWJpbGl0eSBiYXJyaWVyIGlu IHRoZSB3YXkgb2YgcGVvcGxlIHVzaW5nIHRoZSBFMkUgbW9kZS4gV2hpbGUgV2lyZSBpcyBmdWxs eSBFMkUsIEkgYmVsaWV2ZSB0aGF0IHRoZXkgc2ltaWxhcmx5IGFsbG93IGxvZ2dpbmcgaW50byBh IG5ldyBkZXZpY2Ugd2l0aG91dCBhbnkgaW50ZXJhY3Rpb24gd2l0aCBvbGQgZGV2aWNlcy4gQXMg ZmFyIGFzIEnigJltIGF3YXJlLCBuZWl0aGVyIHNlcnZpY2Ugc3luY2hyb25pc2VzIGRlY3J5cHRp b24ga2V5cyBiZXR3ZWVuIGRldmljZXMsIGFuZCB3ZSBpbnN0ZWFkIGp1c3QgdHJlYXQgZWFjaCBu ZXcgZGV2aWNlIGFzIGVmZmVjdGl2ZWx5IGEgbmV3IGdyb3VwIHBhcnRpY2lwYW50Lg0KDQpIb3dl dmVyIHRoZXJlIGlzIGEgdGhpcmQgb3B0aW9uIHRoYXQgd2UgYWxsdWRlZCB0byBpbiB0aGUgQVJU IHBhcGVyLCB0aGF0IHNpdHMgc29tZXdoZXJlIGJldHdlZW4geW91ciBvcHRpb25zIDAgYW5kIDEu DQoNCjIpIEdpdmUgZWFjaCB1c2VyIGFzIGEgc2VwYXJhdGUgQVJUIHN1YnRyZWUuIFRoZSBsZWF2 ZXMgb2YgdGhlIGdyb3VwIHRocmVhZCB0cmVlIHdvdWxkIHRoZW4gc2ltcGx5IGJlIHRoZSByb290 cyBvZiBlYWNoIHVzZXLigJlzIHN1YnRyZWUuIFlvdSBjYW4gdGhlbiB1c2UgdGhpcyB0byBtYXNr IHRoZSBudW1iZXIgb2YgZGV2aWNlcyBlYWNoIHVzZXIgaGFzLCBidXQgd2l0aG91dCBzeW5jaHJv bmlzaW5nIHRoZWlyIHByaXZhdGUga2V5IG1hdGVyaWFsLiBUaGUgc2FtZSBhbGdvcml0aG1zIHdv dWxkIGFwcGx5IHRvIHRoZSBzdWJ0cmVlcywgc28gd2XigJlkIGdldCBGUyBhbmQgUENTIHdpdGgg cmVzcGVjdCB0byBlYWNoIGRldmljZSDigJMgaW5jbHVkaW5nIHdoZW4gdGhleeKAmXJlIGFkZGVk IGFuZCByZW1vdmVkLg0KDQpUaGlzIG9wdGlvbiBjb3VsZCBiZSBxdWl0ZSBmbGV4aWJsZSwgc28g eW91IGNvdWxkIHRoZW4gbWFrZSBhIG51bWJlciBvZiB0aGUgZGVzaWduIGNob2ljZXMgZGlzY3Vz c2VkIGFwcGxpY2F0aW9uLXNwZWNpZmljLiBFLmcuIGlmIHlvdSB3YW50IHRvIHJlcXVpcmUgbmV3 IGRldmljZXMgb24gYW4gYWNjb3VudCB0byBiZSBlbnJvbGxlZCBieSBvdGhlcnMsIHRoZW4geW91 IGNhbiBkbyB0aGlzIHdpdGhvdXQgc3VyZmFjaW5nIGFueSB3YXJuaW5ncy4gT3RoZXJ3aXNlIHlv dSBjb3VsZCBjaG9vc2UgdG8gbm90aWZ5IHRoYXQgdGhlIHVzZXLigJlzIGxlYWYgY2hhbmdlZDog b3IgZXZlbiB0aGUgZnVsbCBsaXN0IG9mIGVhY2ggdXNlcuKAmXMgZGV2aWNlcyBpZiB5b3Ugd2lz aGVkLg0KDQpKb24NCg0KT24gMjQvMDMvMjAxOCwgMjI6NDMsICJNTFMgb24gYmVoYWxmIG9mIEVy aWMgUmVzY29ybGEiIDxtbHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bWxzLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdy b3RlOg0KDQoNCg0KT24gU2F0LCBNYXIgMjQsIDIwMTggYXQgMTA6MzIgUE0sIERhbmllbCBLYWhu IEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldDxtYWlsdG86ZGtnQGZpZnRoaG9yc2VtYW4u bmV0Pj4gd3JvdGU6DQpJbiB0aGUgQm9GIGF0IElFVEYgMTAxLCBJIGV4cHJlc3NlZCBteSBjb25j ZXJuIGFib3V0IHRoZSB3YXkgdGhhdA0KbXVsdGlwbGUgZGV2aWNlcyBmaXRzIGluIHRoZSBhcmNo aXRlY3R1cmFsIHJlcXVpcmVtZW50cy4gIEknbSByZXBlYXRpbmcNCnRob3NlIGNvbmNlcm5zIG9u LWxpc3QgaGVyZSBpbiB0aGUgaG9wZXMgb2YgcmFpc2luZyBvbi1saXN0IGRpc2N1c3Npb24sDQph bmQgdHJ5aW5nIHRvIGZsZXNoIHRoZW0gb3V0IGhlcmUgaW4gbW9yZSBkZXRhaWwuDQoNCkkgc2Vl IHR3byB1c2UgY2FzZXMgdGhhdCBtaWdodCBjb21lIHVuZGVyIHRoZSAibXVsdGktZGV2aWNlIiBy dWJyaWM6DQoNCiBhKSBkZXZpY2UgbG9zcy9yZWNvdmVyeQ0KDQogYikgYWN0dWFsIGNvbmN1cnJl bnQgdXNlIChlLmcuIGxhcHRvcCArIGRlc2t0b3AgKyBtb2JpbGUpDQoNCmknbGwgZm9jdXMgaGVy ZSBtYWlubHkgb24gKGIpLCBzaW5jZSBpIHRoaW5rIChhKSBpcyBhIGRpc3RpbmN0DQpzaXR1YXRp b24uDQoNClByaXZhY3kgQ29uc2lkZXJhdGlvbnMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K SXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBhbnkgdXNlciBoYXMgYSBzaXR1YXRpb24gd2hlcmUg dGhleSAqd2FudCogdG8NCmluZGljYXRlIHRvIG90aGVyIHVzZXJzIG9mIHRoZSBncm91cCB3aGlj aCBkZXZpY2UgdGhleSdyZSB1c2luZy4NCg0KUmVhbGx5PyBCZWNhdXNlIHRoaXMga2luZCBvZiBz dGF0dXMgcmVwb3J0aW5nIGlzIGFjdHVhbGx5IGEgcmVhc29uYWJseSBjb21tb24NCmZlYXR1cmUg b2YgSU0gc3lzdGVtcy4NCg0KDQpTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KV2hlbiB0aGUgdXNlciBoYXMgbXVsdGlwbGUgZGV2aWNlcywgdGhlcmUg YXJlIHR3byBwb3NzaWJsZSBhcHByb2FjaGVzOg0KDQogMCkgc2hhcmluZyBkZWNyeXB0aW9uLWNh cGFibGUga2V5cyBhY3Jvc3MgZGV2aWNlcyAocGVlcnMgc2VlIGEgc2luZ2xlDQogICAga2V5IGZv ciBlYWNoIHVzZXIpDQoNCiAxKSBkaXN0aW5jdCBwZXItZGV2aWNlIGRlY3J5cHRpb24tY2FwYWJs ZSBrZXlzIChwZWVycyBzZWUgbXVsdGlwbGUga2V5cw0KICAgIHBlciB1c2VyKQ0KDQpPbmUgcG90 ZW50aWFsIGFyZ3VtZW50IGlzIHRoYXQgb3B0aW9uICgxKSBtaWdodCBwcm92aWRlDQoidHJhbnNw YXJlbmN5IiAtLSBvciB2aXNpYmlsaXR5IG9mIGEga2V5IGNoYW5nZSBpbiB0aGUgZXZlbnQgb2Yg YW4NCmFkdmVyc2FyeSB3aG8gdHJpZXMgdG8gY2hhbmdlIHRoZSBrZXlzIG9mIGEgY2xpZW50LiAg YnV0IGkgZG9uJ3QgdGhpbmsNCnRoaXMgYXJndW1lbnQgd29ya3MuDQoNClRoZSByZWFzb24gZm9y ICMxIGlzbid0IHRyYW5zcGFyZW5jeSwgaXQncyB0aGF0IHRoZXJlIGFyZSB1c2UgY2FzZXMgaW4N CndoaWNoIHVzZXJzIHdhbnQgdG8gYWRkIGEgbmV3IGRldmljZSB3aXRob3V0IGFuIGV4aXN0aW5n IGRldmljZSBiZWluZw0Kb25saW5lLCBhbmQgdGhlc2UgYXJlIGluY29tcGF0aWJsZSB3aXRoIHR5 cGUgIzAgZGVzaWducy4NCg0KDQoNCkZ1cnRoZXJtb3JlLCBpdCdzIG5vdCBjbGVhciB3aGF0IGEg Z3JvdXAgY29udmVyc2F0aW9uIHBhcnRpY2lwYW50IGNhbg0KKmRvKiwgc2VjdXJpdHktd2lzZSwg aW4gdGhlIGV2ZW50IG9mIHJlY2lldmluZyBzdWNoIGEgbWVzc2FnZSBmcm9tDQphbm90aGVyIHBh cnRpY2lwYW50IC0tIGlzIHRoaXMgYWN0dWFsbHkgYSBuZXcgcGhvbmUsIG9yIGlzIGl0IGEgd2ly ZXRhcA0KaW5qZWN0aW9uPyAgc2hvdWxkIGkgYXNrIHRoZSB1c2VyIGFib3V0IGl0PyAgc2hvdWxk IGkgdGFrZSBhY3Rpb24/ICB3aGF0DQpjdGlvbj8NCg0KR2VuZXJhbGx5LCBJIHdvdWxkbid0IGV4 cGVjdCB0aGVtIHRvIHRha2UgYW55IGFjdGlvbiBhdCBhbGwuIEl0J3MgYSB1c2VyJ3MNCnJlc3Bv bnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHRoZSByaWdodCBudW1iZXIgb2YgZGV2aWNlcyBhcmUg cmVnaXN0ZXJlZA0KdG8gdGhlaXIgYWNjb3VudCwganVzdCBhcyBpdHMgY29tbW9uIGZvciB0aGUg bnVtYmVyIG9mIFdlYiBicm93c2Vycw0Kb25lIGhhcyBhdHRhY2hlZCB0byBvbmVzIEdtYWlsIGFj Y291bnQuDQoNCg0KVG8gYXZvaWQgVVggd2FybmluZyBmYXRpZ3VlLCBpJ20gd2FyeSBhYm91dCBp bnRyb2R1Y2luZyBtb3JlIG9mIHRoZXNlDQpldmVudHMgdGhhbiBhcmUgc3RyaWN0bHkgbmVjZXNz YXJ5IChzY2VuYXJpbyAoYSkgYWJvdmUgcHJvYmFibHkNCnJlcHJlc2VudHMgYSAibmVjZXNzYXJ5 IiBldmVudCwgc2FkbHksIGJ1dCAiaSBqdXN0IGdvdCBhIG5ldyBwaG9uZSINCmRvZXNuJ3Qgc2Vl bSBuZWNlc3NhcnkpLg0KDQpBbmQgZmluYWxseSwgd2UgcHJlc3VtYWJseSB3YW50IGFueSBzb3J0 IG9mIGRldmljZSBjaGFuZ2UgdG8gYmUNCmF1dGhvcml6ZWQgZnJvbSBhbiBhbHJlYWR5LWtub3du IGRldmljZSBmb3IgdGhlIHNhbWUgdXNlci4NCg0KVGhpcyB3YXMgbm90IGluIGZhY3QgbXkgYXNz dW1wdGlvbiwgZm9yIHRoZSByZWFzb24gaW5kaWNhdGVkIGFib3ZlDQoNCi1Fa3INCg0K --_000_02DC72FA0C574A1B920D4B456121CC55fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9D1D77DF52D6EF478A02BB0C2348DE76@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PknigJlkIGxpa2UgdG8gc2Vjb25kIEVrcuKAmXMgcG9pbnRzIGhlcmUuIFRvIHByb3ZpZGUgYSBj b25jcmV0ZSB1c2UgY2FzZSwgaW4gRmFjZWJvb2sgTWVzc2VuZ2VyLCB3ZSB3YW50IFNlY3JldCBD b252ZXJzYXRpb25zIHRvIHdvcmsgZm9yIGEgdXNlciBhcyBzb29uIGFzIHRoZXkgbG9nIGluIG9u IGEgbmV3IGRldmljZS4gVGhpcyBzb21ld2hhdA0KIGJsdXJzIHRoZSBib3VuZGFyeSBiZXR3ZWVu IGRldmljZSBsb3NzL3JlY292ZXJ5IGFuZCBjb25jdXJyZW50IHVzZSBhcyBpdCBpcyB1c2VkIGZv ciBib3RoIHNpdHVhdGlvbnM7IGJ1dCB3ZSBkb27igJl0IHdhbnQgdG8gcmVxdWlyZSBleGlzdGlu ZyBkZXZpY2UgdG8gYXV0aG9yaXNlIG5ldyBkZXZpY2VzIGFzIOKAkyB0byBiZSBwZXJmZWN0bHkg ZnJhbmsg4oCTIHdl4oCZcmUgbm90IGNvbnZpbmNlZCB0aGF0IG1vc3QgcGVvcGxlIHdvdWxkIGFj dHVhbGx5IGRvDQogdGhpcywgYW5kIGl0IHB1dHMgYSBwb3RlbnRpYWwgdXNhYmlsaXR5IGJhcnJp ZXIgaW4gdGhlIHdheSBvZiBwZW9wbGUgdXNpbmcgdGhlIEUyRSBtb2RlLiBXaGlsZSBXaXJlIGlz IGZ1bGx5IEUyRSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaW1pbGFybHkgYWxsb3cgbG9nZ2luZyBp bnRvIGEgbmV3IGRldmljZSB3aXRob3V0IGFueSBpbnRlcmFjdGlvbiB3aXRoIG9sZCBkZXZpY2Vz LiBBcyBmYXIgYXMgSeKAmW0gYXdhcmUsIG5laXRoZXIgc2VydmljZSBzeW5jaHJvbmlzZXMNCiBk ZWNyeXB0aW9uIGtleXMgYmV0d2VlbiBkZXZpY2VzLCBhbmQgd2UgaW5zdGVhZCBqdXN0IHRyZWF0 IGVhY2ggbmV3IGRldmljZSBhcyBlZmZlY3RpdmVseSBhIG5ldyBncm91cCBwYXJ0aWNpcGFudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SG93ZXZlciB0aGVyZSBpcyBhIHRoaXJkIG9wdGlvbiB0aGF0IHdlIGFsbHVkZWQgdG8g aW4gdGhlIEFSVCBwYXBlciwgdGhhdCBzaXRzIHNvbWV3aGVyZSBiZXR3ZWVuIHlvdXIgb3B0aW9u cyAwIGFuZCAxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4yKSBHaXZlIGVhY2ggdXNlciBhcyBhIHNlcGFyYXRlIEFSVCBzdWJ0 cmVlLiBUaGUgbGVhdmVzIG9mIHRoZSBncm91cCB0aHJlYWQgdHJlZSB3b3VsZCB0aGVuIHNpbXBs eSBiZSB0aGUgcm9vdHMgb2YgZWFjaCB1c2Vy4oCZcyBzdWJ0cmVlLiBZb3UgY2FuIHRoZW4gdXNl IHRoaXMgdG8gbWFzayB0aGUgbnVtYmVyIG9mIGRldmljZXMgZWFjaCB1c2VyDQogaGFzLCBidXQg d2l0aG91dCBzeW5jaHJvbmlzaW5nIHRoZWlyIHByaXZhdGUga2V5IG1hdGVyaWFsLiBUaGUgc2Ft ZSBhbGdvcml0aG1zIHdvdWxkIGFwcGx5IHRvIHRoZSBzdWJ0cmVlcywgc28gd2XigJlkIGdldCBG UyBhbmQgUENTIHdpdGggcmVzcGVjdCB0byBlYWNoIGRldmljZSDigJMgaW5jbHVkaW5nIHdoZW4g dGhleeKAmXJlIGFkZGVkIGFuZCByZW1vdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlzIG9wdGlvbiBjb3VsZCBiZSBx dWl0ZSBmbGV4aWJsZSwgc28geW91IGNvdWxkIHRoZW4gbWFrZSBhIG51bWJlciBvZiB0aGUgZGVz aWduIGNob2ljZXMgZGlzY3Vzc2VkIGFwcGxpY2F0aW9uLXNwZWNpZmljLiBFLmcuIGlmIHlvdSB3 YW50IHRvIHJlcXVpcmUgbmV3IGRldmljZXMgb24gYW4gYWNjb3VudCB0byBiZSBlbnJvbGxlZCBi eQ0KIG90aGVycywgdGhlbiB5b3UgY2FuIGRvIHRoaXMgd2l0aG91dCBzdXJmYWNpbmcgYW55IHdh cm5pbmdzLiBPdGhlcndpc2UgeW91IGNvdWxkIGNob29zZSB0byBub3RpZnkgdGhhdCB0aGUgdXNl cuKAmXMgbGVhZiBjaGFuZ2VkOiBvciBldmVuIHRoZSBmdWxsIGxpc3Qgb2YgZWFjaCB1c2Vy4oCZ cyBkZXZpY2VzIGlmIHlvdSB3aXNoZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkpvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAyNC8wMy8yMDE4LCAy Mjo0MywgJnF1b3Q7TUxTIG9uIGJlaGFsZiBvZiBFcmljIFJlc2NvcmxhJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bWxzLWJvdW5jZXNAaWV0Zi5vcmciPm1scy1ib3VuY2VzQGlldGYub3JnPC9h PiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNw OzwvbzpwPjwvYT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPk9uIFNhdCwgTWFyIDI0LCAyMDE4IGF0IDEwOjMyIFBNLCBEYW5p ZWwgS2FobiBHaWxsbW9yICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRrZ0BmaWZ0aGhvcnNl bWFuLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPmRrZ0BmaWZ0aGhvcnNlbWFuLm5ldDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ SW4gdGhlIEJvRiBhdCBJRVRGIDEwMSwgSSBleHByZXNzZWQgbXkgY29uY2VybiBhYm91dCB0aGUg d2F5IHRoYXQ8YnI+DQptdWx0aXBsZSBkZXZpY2VzIGZpdHMgaW4gdGhlIGFyY2hpdGVjdHVyYWwg cmVxdWlyZW1lbnRzLiZuYnNwOyBJJ20gcmVwZWF0aW5nPGJyPg0KdGhvc2UgY29uY2VybnMgb24t bGlzdCBoZXJlIGluIHRoZSBob3BlcyBvZiByYWlzaW5nIG9uLWxpc3QgZGlzY3Vzc2lvbiw8YnI+ DQphbmQgdHJ5aW5nIHRvIGZsZXNoIHRoZW0gb3V0IGhlcmUgaW4gbW9yZSBkZXRhaWwuPGJyPg0K PGJyPg0KSSBzZWUgdHdvIHVzZSBjYXNlcyB0aGF0IG1pZ2h0IGNvbWUgdW5kZXIgdGhlICZxdW90 O211bHRpLWRldmljZSZxdW90OyBydWJyaWM6PGJyPg0KPGJyPg0KJm5ic3A7YSkgZGV2aWNlIGxv c3MvcmVjb3Zlcnk8YnI+DQo8YnI+DQombmJzcDtiKSBhY3R1YWwgY29uY3VycmVudCB1c2UgKGUu Zy4gbGFwdG9wICYjNDM7IGRlc2t0b3AgJiM0MzsgbW9iaWxlKTxicj4NCjxicj4NCmknbGwgZm9j dXMgaGVyZSBtYWlubHkgb24gKGIpLCBzaW5jZSBpIHRoaW5rIChhKSBpcyBhIGRpc3RpbmN0PGJy Pg0Kc2l0dWF0aW9uLjxicj4NCjxicj4NClByaXZhY3kgQ29uc2lkZXJhdGlvbnM8YnI+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KSXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBh bnkgdXNlciBoYXMgYSBzaXR1YXRpb24gd2hlcmUgdGhleSAqd2FudCogdG88YnI+DQppbmRpY2F0 ZSB0byBvdGhlciB1c2VycyBvZiB0aGUgZ3JvdXAgd2hpY2ggZGV2aWNlIHRoZXkncmUgdXNpbmcu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJl YWxseT8gQmVjYXVzZSB0aGlzIGtpbmQgb2Ygc3RhdHVzIHJlcG9ydGluZyBpcyBhY3R1YWxseSBh IHJlYXNvbmFibHkgY29tbW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ZmVhdHVyZSBvZiBJTSBzeXN0ZW1z LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPlNlY3VyaXR5IENvbnNpZGVyYXRpb25zPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQo8YnI+DQpXaGVuIHRoZSB1c2VyIGhhcyBtdWx0aXBsZSBkZXZpY2Vz LCB0aGVyZSBhcmUgdHdvIHBvc3NpYmxlIGFwcHJvYWNoZXM6PGJyPg0KPGJyPg0KJm5ic3A7MCkg c2hhcmluZyBkZWNyeXB0aW9uLWNhcGFibGUga2V5cyBhY3Jvc3MgZGV2aWNlcyAocGVlcnMgc2Vl IGEgc2luZ2xlPGJyPg0KJm5ic3A7ICZuYnNwOyBrZXkgZm9yIGVhY2ggdXNlcik8YnI+DQo8YnI+ DQombmJzcDsxKSBkaXN0aW5jdCBwZXItZGV2aWNlIGRlY3J5cHRpb24tY2FwYWJsZSBrZXlzIChw ZWVycyBzZWUgbXVsdGlwbGUga2V5czxicj4NCiZuYnNwOyAmbmJzcDsgcGVyIHVzZXIpPGJyPg0K PGJyPg0KT25lIHBvdGVudGlhbCBhcmd1bWVudCBpcyB0aGF0IG9wdGlvbiAoMSkgbWlnaHQgcHJv dmlkZTxicj4NCiZxdW90O3RyYW5zcGFyZW5jeSZxdW90OyAtLSBvciB2aXNpYmlsaXR5IG9mIGEg a2V5IGNoYW5nZSBpbiB0aGUgZXZlbnQgb2YgYW48YnI+DQphZHZlcnNhcnkgd2hvIHRyaWVzIHRv IGNoYW5nZSB0aGUga2V5cyBvZiBhIGNsaWVudC4mbmJzcDsgYnV0IGkgZG9uJ3QgdGhpbms8YnI+ DQp0aGlzIGFyZ3VtZW50IHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5UaGUgcmVhc29uIGZvciAjMSBpc24ndCB0cmFuc3BhcmVuY3ksIGl0J3Mg dGhhdCB0aGVyZSBhcmUgdXNlIGNhc2VzIGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+d2hpY2ggdXNlcnMg d2FudCB0byBhZGQgYSBuZXcgZGV2aWNlIHdpdGhvdXQgYW4gZXhpc3RpbmcgZGV2aWNlIGJlaW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+b25saW5lLCBhbmQgdGhlc2UgYXJlIGluY29tcGF0aWJsZSB3aXRo IHR5cGUgIzAgZGVzaWducy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5G dXJ0aGVybW9yZSwgaXQncyBub3QgY2xlYXIgd2hhdCBhIGdyb3VwIGNvbnZlcnNhdGlvbiBwYXJ0 aWNpcGFudCBjYW48YnI+DQoqZG8qLCBzZWN1cml0eS13aXNlLCBpbiB0aGUgZXZlbnQgb2YgcmVj aWV2aW5nIHN1Y2ggYSBtZXNzYWdlIGZyb208YnI+DQphbm90aGVyIHBhcnRpY2lwYW50IC0tIGlz IHRoaXMgYWN0dWFsbHkgYSBuZXcgcGhvbmUsIG9yIGlzIGl0IGEgd2lyZXRhcDxicj4NCmluamVj dGlvbj8mbmJzcDsgc2hvdWxkIGkgYXNrIHRoZSB1c2VyIGFib3V0IGl0PyZuYnNwOyBzaG91bGQg aSB0YWtlIGFjdGlvbj8mbmJzcDsgd2hhdDxicj4NCmN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5HZW5lcmFsbHksIEkgd291bGRuJ3QgZXhwZWN0 IHRoZW0gdG8gdGFrZSBhbnkgYWN0aW9uIGF0IGFsbC4gSXQncyBhIHVzZXInczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPnJlc3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHRoZSByaWdodCBudW1iZXIgb2Yg ZGV2aWNlcyBhcmUgcmVnaXN0ZXJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnRvIHRoZWlyIGFjY291bnQs IGp1c3QgYXMgaXRzIGNvbW1vbiBmb3IgdGhlIG51bWJlciBvZiBXZWIgYnJvd3NlcnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij5vbmUgaGFzIGF0dGFjaGVkIHRvIG9uZXMgR21haWwgYWNjb3VudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpUbyBhdm9pZCBV WCB3YXJuaW5nIGZhdGlndWUsIGknbSB3YXJ5IGFib3V0IGludHJvZHVjaW5nIG1vcmUgb2YgdGhl c2U8YnI+DQpldmVudHMgdGhhbiBhcmUgc3RyaWN0bHkgbmVjZXNzYXJ5IChzY2VuYXJpbyAoYSkg YWJvdmUgcHJvYmFibHk8YnI+DQpyZXByZXNlbnRzIGEgJnF1b3Q7bmVjZXNzYXJ5JnF1b3Q7IGV2 ZW50LCBzYWRseSwgYnV0ICZxdW90O2kganVzdCBnb3QgYSBuZXcgcGhvbmUmcXVvdDs8YnI+DQpk b2Vzbid0IHNlZW0gbmVjZXNzYXJ5KS48YnI+DQo8YnI+DQpBbmQgZmluYWxseSwgd2UgcHJlc3Vt YWJseSB3YW50IGFueSBzb3J0IG9mIGRldmljZSBjaGFuZ2UgdG8gYmU8YnI+DQphdXRob3JpemVk IGZyb20gYW4gYWxyZWFkeS1rbm93biBkZXZpY2UgZm9yIHRoZSBzYW1lIHVzZXIuJm5ic3A7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGlzIHdhcyBu b3QgaW4gZmFjdCBteSBhc3N1bXB0aW9uLCBmb3IgdGhlIHJlYXNvbiBpbmRpY2F0ZWQgYWJvdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4tRWtyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_02DC72FA0C574A1B920D4B456121CC55fbcom_-- From nobody Sat Mar 24 16:40:42 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C251127023 for ; Sat, 24 Mar 2018 16:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=fI7IDrfc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=ZAAEWz5K 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 6r3RJ_B_Wa-c for ; Sat, 24 Mar 2018 16:40:37 -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 CA67612025C for ; Sat, 24 Mar 2018 16:40:37 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2ONdiU9020962; Sat, 24 Mar 2018 16:40:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=ZD0DXrv8TUqZ6qjPKfHa07pC/mOV2dJMAOB7W4PT5A4=; b=fI7IDrfc5Y700r2GZd8Wit4Qjtoki1yBLN/YGz+6QRMMrFCSFvnPXUIM3mE7vjeakzGC W2xrtWq/+sKbMzmOqo0huilIWQgDWFlNyD31YA3hYuvB10NJfBMb2BrGaimmSOi4aVdm LOCmoZCpK0B2MrCgdUZqHa6u4siDUF9Z4eM= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2gwxeq066p-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2018 16:40:36 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 16:40:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZD0DXrv8TUqZ6qjPKfHa07pC/mOV2dJMAOB7W4PT5A4=; b=ZAAEWz5KG66xckAkeVoDklSfuBRfSsao0r2NTmOjJBOq+yaj50rCjmqIOwf7QtfvJlLpL/g1GS5equKJPDQDcBh7/oDdVgMYItOz74cbqPryLa0BDcLunxQJqrhlIH2k132s9j/a/cyHfyyPbPlCUezIT2yQ/lhYxQuHiYvpyHw= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1654.namprd15.prod.outlook.com (10.175.120.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Sat, 24 Mar 2018 23:40:32 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0609.012; Sat, 24 Mar 2018 23:40:32 +0000 From: Jon Millican To: Eric Rescorla , Daniel Kahn Gillmor CC: "mls@ietf.org" Thread-Topic: [MLS] multiple devices per user? Thread-Index: AQHTw8Ae2CgUeIFvK0mYODDXyt5r4qPf+1KAgAAHQoCAAAjpgA== Date: Sat, 24 Mar 2018 23:40:32 +0000 Message-ID: References: <87efk9m7e9.fsf@fifthhorseman.net> <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> In-Reply-To: <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.39.102.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1654; 7:2uOGKOALVpYY8CBKKqNy37gtIw4/mcn9vI7PSNLmSyISEmkXMgNm0Dph4pD93EiqxE1al9EFcGOpIAjW1m8oT3TRT/fSw5djKTj++ERrYVq0e99qaqtFepCQfCNc0cUldr6lrx1QBDFIlt+I1r3bWAHG0VZIVJbn31/R0gH47pxLU3NvRqMdwomzXkHOoLxtbgal106BpHomYFuJ+p4QdQBHR7bhT/9g6iZFKoyXx3oT6v2qmBcSpRh9aIbRVIuP; 20:dAWnus4zz2TnRzVcl34oOU2R2x1kAXzr8k3uGU2dHaILM0h0h1SmGzCzYs8yNCbJcIsB2aoR4miUuYqGfimyyFlNXNspGgCdOQKdKXSCHX+8tXQ9P6M8kgmJRyprxLS3tLB773hXAV0kJeGD8N3MI4vSUwfdhyiLSdt2ZjtrJmA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a8c0793a-e76a-41f2-2bab-08d591e0a266 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1654; x-ms-traffictypediagnostic: CY4PR15MB1654: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(209352067349851)(192374486261705)(67672495146484)(81227570615382)(21748063052155)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(10201501046)(6041310)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR15MB1654; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1654; x-forefront-prvs: 0621E7E436 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39380400002)(39860400002)(346002)(199004)(189003)(76176011)(3846002)(83716003)(81166006)(6306002)(110136005)(14454004)(55236004)(186003)(53936002)(5250100002)(6116002)(3660700001)(25786009)(11346002)(6512007)(2906002)(6506007)(53546011)(26005)(3280700002)(102836004)(6436002)(99286004)(68736007)(236005)(59450400001)(446003)(316002)(4326008)(8936002)(5660300001)(86362001)(81156014)(7736002)(8676002)(478600001)(33656002)(2900100001)(229853002)(66066001)(82746002)(97736004)(6486002)(5890100001)(36756003)(106356001)(6246003)(54896002)(105586002)(2616005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1654; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RJLWthenUS7oIzuWh91GUs4LTawUdLFK+yp3zLMvCdmdzu23xXwCqpKBxsBFqCV5ZDZgvVvSDtjPwRxqQm7PHggnaGesDGZ3O+c9EUFlPxZ9IdF04Ivd5CDB1wBdEIPoUk4H8QZDcZnECy8aXDrnaH1oXzOyqZtZfOQwIcByDgZM1Dxyatr0fpP3wQr7W4uTivTq/IXlAr+AASltpa/yFx0I5TGBUfqBJPiVFSYx6O687sHZ5UAmr1O3D6dwLtszlKH86KuyUa+OKdR8/X08mpqWfeUnUbSFQ9Sa2GAY+nYPGQSyzFvZeTtFeXQM3q5XL9XsXWOlGsmZ4wNWZKhUCg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B0F25392001543228B4D22E8E2A73375fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a8c0793a-e76a-41f2-2bab-08d591e0a266 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2018 23:40:32.5162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1654 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-24_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 23:40:40 -0000 --_000_B0F25392001543228B4D22E8E2A73375fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzaG91bGQgbWVudGlvbiB0aGF0IHRoaXMgdGhpcmQgb3B0aW9uIOKAkyBhdCBsZWFzdCBpbiB0 aGUgY29udGV4dCBvZiBNTFMg4oCTIGlzIGN1cnJlbnRseSBzb21ldGhpbmcgb2YgYSBoYWxmLWJh a2VkIGlkZWEuIEl04oCZcyBhbiBhcHByb2FjaCB0aGF0IHNob3VsZCB3b3JrIGluIGEgaHlwb3Ro ZXRpY2FsIEFSVC1iYXNlZCBwcm90b2NvbCwgYnV0IHdlIGhhdmVu4oCZdCBkdWcgaW50byBpdCBl bm91Z2ggdG8gZmlndXJlIG91dCB3aGV0aGVyIGl0IHdpbGwgZml0IGludG8gdGhlIHByb3Bvc2Vk IGNvbnN0cmFpbnRzIGZvciBNTFMuDQoNCk9uIDI0LzAzLzIwMTgsIDIzOjA4LCAiSm9uIE1pbGxp Y2FuIiA8am1pbGxpY2FuQGZiLmNvbTxtYWlsdG86am1pbGxpY2FuQGZiLmNvbT4+IHdyb3RlOg0K DQpJ4oCZZCBsaWtlIHRvIHNlY29uZCBFa3LigJlzIHBvaW50cyBoZXJlLiBUbyBwcm92aWRlIGEg Y29uY3JldGUgdXNlIGNhc2UsIGluIEZhY2Vib29rIE1lc3Nlbmdlciwgd2Ugd2FudCBTZWNyZXQg Q29udmVyc2F0aW9ucyB0byB3b3JrIGZvciBhIHVzZXIgYXMgc29vbiBhcyB0aGV5IGxvZyBpbiBv biBhIG5ldyBkZXZpY2UuIFRoaXMgc29tZXdoYXQgYmx1cnMgdGhlIGJvdW5kYXJ5IGJldHdlZW4g ZGV2aWNlIGxvc3MvcmVjb3ZlcnkgYW5kIGNvbmN1cnJlbnQgdXNlIGFzIGl0IGlzIHVzZWQgZm9y IGJvdGggc2l0dWF0aW9uczsgYnV0IHdlIGRvbuKAmXQgd2FudCB0byByZXF1aXJlIGV4aXN0aW5n IGRldmljZSB0byBhdXRob3Jpc2UgbmV3IGRldmljZXMgYXMg4oCTIHRvIGJlIHBlcmZlY3RseSBm cmFuayDigJMgd2XigJlyZSBub3QgY29udmluY2VkIHRoYXQgbW9zdCBwZW9wbGUgd291bGQgYWN0 dWFsbHkgZG8gdGhpcywgYW5kIGl0IHB1dHMgYSBwb3RlbnRpYWwgdXNhYmlsaXR5IGJhcnJpZXIg aW4gdGhlIHdheSBvZiBwZW9wbGUgdXNpbmcgdGhlIEUyRSBtb2RlLiBXaGlsZSBXaXJlIGlzIGZ1 bGx5IEUyRSwgSSBiZWxpZXZlIHRoYXQgdGhleSBzaW1pbGFybHkgYWxsb3cgbG9nZ2luZyBpbnRv IGEgbmV3IGRldmljZSB3aXRob3V0IGFueSBpbnRlcmFjdGlvbiB3aXRoIG9sZCBkZXZpY2VzLiBB cyBmYXIgYXMgSeKAmW0gYXdhcmUsIG5laXRoZXIgc2VydmljZSBzeW5jaHJvbmlzZXMgZGVjcnlw dGlvbiBrZXlzIGJldHdlZW4gZGV2aWNlcywgYW5kIHdlIGluc3RlYWQganVzdCB0cmVhdCBlYWNo IG5ldyBkZXZpY2UgYXMgZWZmZWN0aXZlbHkgYSBuZXcgZ3JvdXAgcGFydGljaXBhbnQuDQoNCkhv d2V2ZXIgdGhlcmUgaXMgYSB0aGlyZCBvcHRpb24gdGhhdCB3ZSBhbGx1ZGVkIHRvIGluIHRoZSBB UlQgcGFwZXIsIHRoYXQgc2l0cyBzb21ld2hlcmUgYmV0d2VlbiB5b3VyIG9wdGlvbnMgMCBhbmQg MS4NCg0KMikgR2l2ZSBlYWNoIHVzZXIgYXMgYSBzZXBhcmF0ZSBBUlQgc3VidHJlZS4gVGhlIGxl YXZlcyBvZiB0aGUgZ3JvdXAgdGhyZWFkIHRyZWUgd291bGQgdGhlbiBzaW1wbHkgYmUgdGhlIHJv b3RzIG9mIGVhY2ggdXNlcuKAmXMgc3VidHJlZS4gWW91IGNhbiB0aGVuIHVzZSB0aGlzIHRvIG1h c2sgdGhlIG51bWJlciBvZiBkZXZpY2VzIGVhY2ggdXNlciBoYXMsIGJ1dCB3aXRob3V0IHN5bmNo cm9uaXNpbmcgdGhlaXIgcHJpdmF0ZSBrZXkgbWF0ZXJpYWwuIFRoZSBzYW1lIGFsZ29yaXRobXMg d291bGQgYXBwbHkgdG8gdGhlIHN1YnRyZWVzLCBzbyB3ZeKAmWQgZ2V0IEZTIGFuZCBQQ1Mgd2l0 aCByZXNwZWN0IHRvIGVhY2ggZGV2aWNlIOKAkyBpbmNsdWRpbmcgd2hlbiB0aGV54oCZcmUgYWRk ZWQgYW5kIHJlbW92ZWQuDQoNClRoaXMgb3B0aW9uIGNvdWxkIGJlIHF1aXRlIGZsZXhpYmxlLCBz byB5b3UgY291bGQgdGhlbiBtYWtlIGEgbnVtYmVyIG9mIHRoZSBkZXNpZ24gY2hvaWNlcyBkaXNj dXNzZWQgYXBwbGljYXRpb24tc3BlY2lmaWMuIEUuZy4gaWYgeW91IHdhbnQgdG8gcmVxdWlyZSBu ZXcgZGV2aWNlcyBvbiBhbiBhY2NvdW50IHRvIGJlIGVucm9sbGVkIGJ5IG90aGVycywgdGhlbiB5 b3UgY2FuIGRvIHRoaXMgd2l0aG91dCBzdXJmYWNpbmcgYW55IHdhcm5pbmdzLiBPdGhlcndpc2Ug eW91IGNvdWxkIGNob29zZSB0byBub3RpZnkgdGhhdCB0aGUgdXNlcuKAmXMgbGVhZiBjaGFuZ2Vk OiBvciBldmVuIHRoZSBmdWxsIGxpc3Qgb2YgZWFjaCB1c2Vy4oCZcyBkZXZpY2VzIGlmIHlvdSB3 aXNoZWQuDQoNCkpvbg0KDQpPbiAyNC8wMy8yMDE4LCAyMjo0MywgIk1MUyBvbiBiZWhhbGYgb2Yg RXJpYyBSZXNjb3JsYSIgPG1scy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbHMtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4g d3JvdGU6DQoNCg0KDQpPbiBTYXQsIE1hciAyNCwgMjAxOCBhdCAxMDozMiBQTSwgRGFuaWVsIEth aG4gR2lsbG1vciA8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PG1haWx0bzpka2dAZmlmdGhob3JzZW1h bi5uZXQ+PiB3cm90ZToNCkluIHRoZSBCb0YgYXQgSUVURiAxMDEsIEkgZXhwcmVzc2VkIG15IGNv bmNlcm4gYWJvdXQgdGhlIHdheSB0aGF0DQptdWx0aXBsZSBkZXZpY2VzIGZpdHMgaW4gdGhlIGFy Y2hpdGVjdHVyYWwgcmVxdWlyZW1lbnRzLiAgSSdtIHJlcGVhdGluZw0KdGhvc2UgY29uY2VybnMg b24tbGlzdCBoZXJlIGluIHRoZSBob3BlcyBvZiByYWlzaW5nIG9uLWxpc3QgZGlzY3Vzc2lvbiwN CmFuZCB0cnlpbmcgdG8gZmxlc2ggdGhlbSBvdXQgaGVyZSBpbiBtb3JlIGRldGFpbC4NCg0KSSBz ZWUgdHdvIHVzZSBjYXNlcyB0aGF0IG1pZ2h0IGNvbWUgdW5kZXIgdGhlICJtdWx0aS1kZXZpY2Ui IHJ1YnJpYzoNCg0KIGEpIGRldmljZSBsb3NzL3JlY292ZXJ5DQoNCiBiKSBhY3R1YWwgY29uY3Vy cmVudCB1c2UgKGUuZy4gbGFwdG9wICsgZGVza3RvcCArIG1vYmlsZSkNCg0KaSdsbCBmb2N1cyBo ZXJlIG1haW5seSBvbiAoYiksIHNpbmNlIGkgdGhpbmsgKGEpIGlzIGEgZGlzdGluY3QNCnNpdHVh dGlvbi4NCg0KUHJpdmFjeSBDb25zaWRlcmF0aW9ucw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpJdCdzIG5vdCBjbGVhciB0byBtZSB0aGF0IGFueSB1c2VyIGhhcyBhIHNpdHVhdGlvbiB3aGVy ZSB0aGV5ICp3YW50KiB0bw0KaW5kaWNhdGUgdG8gb3RoZXIgdXNlcnMgb2YgdGhlIGdyb3VwIHdo aWNoIGRldmljZSB0aGV5J3JlIHVzaW5nLg0KDQpSZWFsbHk/IEJlY2F1c2UgdGhpcyBraW5kIG9m IHN0YXR1cyByZXBvcnRpbmcgaXMgYWN0dWFsbHkgYSByZWFzb25hYmx5IGNvbW1vbg0KZmVhdHVy ZSBvZiBJTSBzeXN0ZW1zLg0KDQoNClNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpXaGVuIHRoZSB1c2VyIGhhcyBtdWx0aXBsZSBkZXZpY2VzLCB0aGVy ZSBhcmUgdHdvIHBvc3NpYmxlIGFwcHJvYWNoZXM6DQoNCiAwKSBzaGFyaW5nIGRlY3J5cHRpb24t Y2FwYWJsZSBrZXlzIGFjcm9zcyBkZXZpY2VzIChwZWVycyBzZWUgYSBzaW5nbGUNCiAgICBrZXkg Zm9yIGVhY2ggdXNlcikNCg0KIDEpIGRpc3RpbmN0IHBlci1kZXZpY2UgZGVjcnlwdGlvbi1jYXBh YmxlIGtleXMgKHBlZXJzIHNlZSBtdWx0aXBsZSBrZXlzDQogICAgcGVyIHVzZXIpDQoNCk9uZSBw b3RlbnRpYWwgYXJndW1lbnQgaXMgdGhhdCBvcHRpb24gKDEpIG1pZ2h0IHByb3ZpZGUNCiJ0cmFu c3BhcmVuY3kiIC0tIG9yIHZpc2liaWxpdHkgb2YgYSBrZXkgY2hhbmdlIGluIHRoZSBldmVudCBv ZiBhbg0KYWR2ZXJzYXJ5IHdobyB0cmllcyB0byBjaGFuZ2UgdGhlIGtleXMgb2YgYSBjbGllbnQu ICBidXQgaSBkb24ndCB0aGluaw0KdGhpcyBhcmd1bWVudCB3b3Jrcy4NCg0KVGhlIHJlYXNvbiBm b3IgIzEgaXNuJ3QgdHJhbnNwYXJlbmN5LCBpdCdzIHRoYXQgdGhlcmUgYXJlIHVzZSBjYXNlcyBp bg0Kd2hpY2ggdXNlcnMgd2FudCB0byBhZGQgYSBuZXcgZGV2aWNlIHdpdGhvdXQgYW4gZXhpc3Rp bmcgZGV2aWNlIGJlaW5nDQpvbmxpbmUsIGFuZCB0aGVzZSBhcmUgaW5jb21wYXRpYmxlIHdpdGgg dHlwZSAjMCBkZXNpZ25zLg0KDQoNCg0KRnVydGhlcm1vcmUsIGl0J3Mgbm90IGNsZWFyIHdoYXQg YSBncm91cCBjb252ZXJzYXRpb24gcGFydGljaXBhbnQgY2FuDQoqZG8qLCBzZWN1cml0eS13aXNl LCBpbiB0aGUgZXZlbnQgb2YgcmVjaWV2aW5nIHN1Y2ggYSBtZXNzYWdlIGZyb20NCmFub3RoZXIg cGFydGljaXBhbnQgLS0gaXMgdGhpcyBhY3R1YWxseSBhIG5ldyBwaG9uZSwgb3IgaXMgaXQgYSB3 aXJldGFwDQppbmplY3Rpb24/ICBzaG91bGQgaSBhc2sgdGhlIHVzZXIgYWJvdXQgaXQ/ICBzaG91 bGQgaSB0YWtlIGFjdGlvbj8gIHdoYXQNCmN0aW9uPw0KDQpHZW5lcmFsbHksIEkgd291bGRuJ3Qg ZXhwZWN0IHRoZW0gdG8gdGFrZSBhbnkgYWN0aW9uIGF0IGFsbC4gSXQncyBhIHVzZXIncw0KcmVz cG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhlIHJpZ2h0IG51bWJlciBvZiBkZXZpY2VzIGFy ZSByZWdpc3RlcmVkDQp0byB0aGVpciBhY2NvdW50LCBqdXN0IGFzIGl0cyBjb21tb24gZm9yIHRo ZSBudW1iZXIgb2YgV2ViIGJyb3dzZXJzDQpvbmUgaGFzIGF0dGFjaGVkIHRvIG9uZXMgR21haWwg YWNjb3VudC4NCg0KDQpUbyBhdm9pZCBVWCB3YXJuaW5nIGZhdGlndWUsIGknbSB3YXJ5IGFib3V0 IGludHJvZHVjaW5nIG1vcmUgb2YgdGhlc2UNCmV2ZW50cyB0aGFuIGFyZSBzdHJpY3RseSBuZWNl c3NhcnkgKHNjZW5hcmlvIChhKSBhYm92ZSBwcm9iYWJseQ0KcmVwcmVzZW50cyBhICJuZWNlc3Nh cnkiIGV2ZW50LCBzYWRseSwgYnV0ICJpIGp1c3QgZ290IGEgbmV3IHBob25lIg0KZG9lc24ndCBz ZWVtIG5lY2Vzc2FyeSkuDQoNCkFuZCBmaW5hbGx5LCB3ZSBwcmVzdW1hYmx5IHdhbnQgYW55IHNv cnQgb2YgZGV2aWNlIGNoYW5nZSB0byBiZQ0KYXV0aG9yaXplZCBmcm9tIGFuIGFscmVhZHkta25v d24gZGV2aWNlIGZvciB0aGUgc2FtZSB1c2VyLg0KDQpUaGlzIHdhcyBub3QgaW4gZmFjdCBteSBh c3N1bXB0aW9uLCBmb3IgdGhlIHJlYXNvbiBpbmRpY2F0ZWQgYWJvdmUNCg0KLUVrcg0KDQo= --_000_B0F25392001543228B4D22E8E2A73375fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBzaG91bGQg bWVudGlvbiB0aGF0IHRoaXMgdGhpcmQgb3B0aW9uIOKAkyBhdCBsZWFzdCBpbiB0aGUgY29udGV4 dCBvZiBNTFMg4oCTIGlzIGN1cnJlbnRseSBzb21ldGhpbmcgb2YgYSBoYWxmLWJha2VkIGlkZWEu IEl04oCZcyBhbiBhcHByb2FjaCB0aGF0IHNob3VsZCB3b3JrIGluIGEgaHlwb3RoZXRpY2FsIEFS VC1iYXNlZCBwcm90b2NvbCwgYnV0DQogd2UgaGF2ZW7igJl0IGR1ZyBpbnRvIGl0IGVub3VnaCB0 byBmaWd1cmUgb3V0IHdoZXRoZXIgaXQgd2lsbCBmaXQgaW50byB0aGUgcHJvcG9zZWQgY29uc3Ry YWludHMgZm9yIE1MUy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjQvMDMvMjAxOCwgMjM6MDgsICZxdW90O0pvbiBNaWxs aWNhbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaWxsaWNhbkBmYi5jb20iPmptaWxsaWNh bkBmYi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SeKAmWQgbGlrZSB0byBzZWNvbmQgRWty4oCZcyBwb2ludHMgaGVyZS4gVG8gcHJvdmlkZSBh IGNvbmNyZXRlIHVzZSBjYXNlLCBpbiBGYWNlYm9vayBNZXNzZW5nZXIsIHdlIHdhbnQgU2VjcmV0 IENvbnZlcnNhdGlvbnMgdG8gd29yayBmb3IgYSB1c2VyIGFzIHNvb24gYXMgdGhleSBsb2cgaW4g b24gYQ0KIG5ldyBkZXZpY2UuIFRoaXMgc29tZXdoYXQgYmx1cnMgdGhlIGJvdW5kYXJ5IGJldHdl ZW4gZGV2aWNlIGxvc3MvcmVjb3ZlcnkgYW5kIGNvbmN1cnJlbnQgdXNlIGFzIGl0IGlzIHVzZWQg Zm9yIGJvdGggc2l0dWF0aW9uczsgYnV0IHdlIGRvbuKAmXQgd2FudCB0byByZXF1aXJlIGV4aXN0 aW5nIGRldmljZSB0byBhdXRob3Jpc2UgbmV3IGRldmljZXMgYXMg4oCTIHRvIGJlIHBlcmZlY3Rs eSBmcmFuayDigJMgd2XigJlyZSBub3QgY29udmluY2VkIHRoYXQgbW9zdA0KIHBlb3BsZSB3b3Vs ZCBhY3R1YWxseSBkbyB0aGlzLCBhbmQgaXQgcHV0cyBhIHBvdGVudGlhbCB1c2FiaWxpdHkgYmFy cmllciBpbiB0aGUgd2F5IG9mIHBlb3BsZSB1c2luZyB0aGUgRTJFIG1vZGUuIFdoaWxlIFdpcmUg aXMgZnVsbHkgRTJFLCBJIGJlbGlldmUgdGhhdCB0aGV5IHNpbWlsYXJseSBhbGxvdyBsb2dnaW5n IGludG8gYSBuZXcgZGV2aWNlIHdpdGhvdXQgYW55IGludGVyYWN0aW9uIHdpdGggb2xkIGRldmlj ZXMuIEFzIGZhciBhcyBJ4oCZbQ0KIGF3YXJlLCBuZWl0aGVyIHNlcnZpY2Ugc3luY2hyb25pc2Vz IGRlY3J5cHRpb24ga2V5cyBiZXR3ZWVuIGRldmljZXMsIGFuZCB3ZSBpbnN0ZWFkIGp1c3QgdHJl YXQgZWFjaCBuZXcgZGV2aWNlIGFzIGVmZmVjdGl2ZWx5IGEgbmV3IGdyb3VwIHBhcnRpY2lwYW50 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Ib3dldmVyIHRoZXJlIGlzIGEgdGhpcmQgb3B0aW9uIHRoYXQgd2UgYWxsdWRlZCB0byBp biB0aGUgQVJUIHBhcGVyLCB0aGF0IHNpdHMgc29tZXdoZXJlIGJldHdlZW4geW91ciBvcHRpb25z IDAgYW5kIDEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjIpIEdpdmUgZWFjaCB1c2VyIGFzIGEgc2VwYXJhdGUgQVJUIHN1YnRyZWUu IFRoZSBsZWF2ZXMgb2YgdGhlIGdyb3VwIHRocmVhZCB0cmVlIHdvdWxkIHRoZW4gc2ltcGx5IGJl IHRoZSByb290cyBvZiBlYWNoIHVzZXLigJlzIHN1YnRyZWUuIFlvdSBjYW4gdGhlbiB1c2UgdGhp cyB0byBtYXNrIHRoZQ0KIG51bWJlciBvZiBkZXZpY2VzIGVhY2ggdXNlciBoYXMsIGJ1dCB3aXRo b3V0IHN5bmNocm9uaXNpbmcgdGhlaXIgcHJpdmF0ZSBrZXkgbWF0ZXJpYWwuIFRoZSBzYW1lIGFs Z29yaXRobXMgd291bGQgYXBwbHkgdG8gdGhlIHN1YnRyZWVzLCBzbyB3ZeKAmWQgZ2V0IEZTIGFu ZCBQQ1Mgd2l0aCByZXNwZWN0IHRvIGVhY2ggZGV2aWNlIOKAkyBpbmNsdWRpbmcgd2hlbiB0aGV5 4oCZcmUgYWRkZWQgYW5kIHJlbW92ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgb3B0aW9uIGNvdWxkIGJlIHF1aXRlIGZs ZXhpYmxlLCBzbyB5b3UgY291bGQgdGhlbiBtYWtlIGEgbnVtYmVyIG9mIHRoZSBkZXNpZ24gY2hv aWNlcyBkaXNjdXNzZWQgYXBwbGljYXRpb24tc3BlY2lmaWMuIEUuZy4gaWYgeW91IHdhbnQgdG8g cmVxdWlyZSBuZXcgZGV2aWNlcyBvbiBhbg0KIGFjY291bnQgdG8gYmUgZW5yb2xsZWQgYnkgb3Ro ZXJzLCB0aGVuIHlvdSBjYW4gZG8gdGhpcyB3aXRob3V0IHN1cmZhY2luZyBhbnkgd2FybmluZ3Mu IE90aGVyd2lzZSB5b3UgY291bGQgY2hvb3NlIHRvIG5vdGlmeSB0aGF0IHRoZSB1c2Vy4oCZcyBs ZWFmIGNoYW5nZWQ6IG9yIGV2ZW4gdGhlIGZ1bGwgbGlzdCBvZiBlYWNoIHVzZXLigJlzIGRldmlj ZXMgaWYgeW91IHdpc2hlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+Sm9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi Pk9uIDI0LzAzLzIwMTgsIDIyOjQzLCAmcXVvdDtNTFMgb24gYmVoYWxmIG9mIEVyaWMgUmVzY29y bGEmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptbHMtYm91bmNlc0BpZXRmLm9yZyI+bWxzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmVrckBydGZt LmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PGEgbmFtZT0iX01haWxPcmlnaW5h bEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9hPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+T24gU2F0LCBNYXIgMjQsIDIwMTgg YXQgMTA6MzIgUE0sIERhbmllbCBLYWhuIEdpbGxtb3IgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86ZGtnQGZpZnRoaG9yc2VtYW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SW4g dGhlIEJvRiBhdCBJRVRGIDEwMSwgSSBleHByZXNzZWQgbXkgY29uY2VybiBhYm91dCB0aGUgd2F5 IHRoYXQ8YnI+DQptdWx0aXBsZSBkZXZpY2VzIGZpdHMgaW4gdGhlIGFyY2hpdGVjdHVyYWwgcmVx dWlyZW1lbnRzLiZuYnNwOyBJJ20gcmVwZWF0aW5nPGJyPg0KdGhvc2UgY29uY2VybnMgb24tbGlz dCBoZXJlIGluIHRoZSBob3BlcyBvZiByYWlzaW5nIG9uLWxpc3QgZGlzY3Vzc2lvbiw8YnI+DQph bmQgdHJ5aW5nIHRvIGZsZXNoIHRoZW0gb3V0IGhlcmUgaW4gbW9yZSBkZXRhaWwuPGJyPg0KPGJy Pg0KSSBzZWUgdHdvIHVzZSBjYXNlcyB0aGF0IG1pZ2h0IGNvbWUgdW5kZXIgdGhlICZxdW90O211 bHRpLWRldmljZSZxdW90OyBydWJyaWM6PGJyPg0KPGJyPg0KJm5ic3A7YSkgZGV2aWNlIGxvc3Mv cmVjb3Zlcnk8YnI+DQo8YnI+DQombmJzcDtiKSBhY3R1YWwgY29uY3VycmVudCB1c2UgKGUuZy4g bGFwdG9wICYjNDM7IGRlc2t0b3AgJiM0MzsgbW9iaWxlKTxicj4NCjxicj4NCmknbGwgZm9jdXMg aGVyZSBtYWlubHkgb24gKGIpLCBzaW5jZSBpIHRoaW5rIChhKSBpcyBhIGRpc3RpbmN0PGJyPg0K c2l0dWF0aW9uLjxicj4NCjxicj4NClByaXZhY3kgQ29uc2lkZXJhdGlvbnM8YnI+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KSXQncyBub3QgY2xlYXIgdG8gbWUgdGhhdCBhbnkg dXNlciBoYXMgYSBzaXR1YXRpb24gd2hlcmUgdGhleSAqd2FudCogdG88YnI+DQppbmRpY2F0ZSB0 byBvdGhlciB1c2VycyBvZiB0aGUgZ3JvdXAgd2hpY2ggZGV2aWNlIHRoZXkncmUgdXNpbmcuJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlYWxs eT8gQmVjYXVzZSB0aGlzIGtpbmQgb2Ygc3RhdHVzIHJlcG9ydGluZyBpcyBhY3R1YWxseSBhIHJl YXNvbmFibHkgY29tbW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ZmVhdHVyZSBvZiBJTSBzeXN0ZW1zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIu MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5TZWN1cml0 eSBDb25zaWRlcmF0aW9uczxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0K V2hlbiB0aGUgdXNlciBoYXMgbXVsdGlwbGUgZGV2aWNlcywgdGhlcmUgYXJlIHR3byBwb3NzaWJs ZSBhcHByb2FjaGVzOjxicj4NCjxicj4NCiZuYnNwOzApIHNoYXJpbmcgZGVjcnlwdGlvbi1jYXBh YmxlIGtleXMgYWNyb3NzIGRldmljZXMgKHBlZXJzIHNlZSBhIHNpbmdsZTxicj4NCiZuYnNwOyAm bmJzcDsga2V5IGZvciBlYWNoIHVzZXIpPGJyPg0KPGJyPg0KJm5ic3A7MSkgZGlzdGluY3QgcGVy LWRldmljZSBkZWNyeXB0aW9uLWNhcGFibGUga2V5cyAocGVlcnMgc2VlIG11bHRpcGxlIGtleXM8 YnI+DQombmJzcDsgJm5ic3A7IHBlciB1c2VyKTxicj4NCjxicj4NCk9uZSBwb3RlbnRpYWwgYXJn dW1lbnQgaXMgdGhhdCBvcHRpb24gKDEpIG1pZ2h0IHByb3ZpZGU8YnI+DQomcXVvdDt0cmFuc3Bh cmVuY3kmcXVvdDsgLS0gb3IgdmlzaWJpbGl0eSBvZiBhIGtleSBjaGFuZ2UgaW4gdGhlIGV2ZW50 IG9mIGFuPGJyPg0KYWR2ZXJzYXJ5IHdobyB0cmllcyB0byBjaGFuZ2UgdGhlIGtleXMgb2YgYSBj bGllbnQuJm5ic3A7IGJ1dCBpIGRvbid0IHRoaW5rPGJyPg0KdGhpcyBhcmd1bWVudCB3b3Jrcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhlIHJlYXNv biBmb3IgIzEgaXNuJ3QgdHJhbnNwYXJlbmN5LCBpdCdzIHRoYXQgdGhlcmUgYXJlIHVzZSBjYXNl cyBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPndoaWNoIHVzZXJzIHdhbnQgdG8gYWRkIGEgbmV3IGRldmlj ZSB3aXRob3V0IGFuIGV4aXN0aW5nIGRldmljZSBiZWluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm9ubGlu ZSwgYW5kIHRoZXNlIGFyZSBpbmNvbXBhdGlibGUgd2l0aCB0eXBlICMwIGRlc2lnbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPkZ1cnRoZXJtb3JlLCBpdCdzIG5vdCBjbGVhciB3aGF0IGEgZ3JvdXAgY29u dmVyc2F0aW9uIHBhcnRpY2lwYW50IGNhbjxicj4NCipkbyosIHNlY3VyaXR5LXdpc2UsIGluIHRo ZSBldmVudCBvZiByZWNpZXZpbmcgc3VjaCBhIG1lc3NhZ2UgZnJvbTxicj4NCmFub3RoZXIgcGFy dGljaXBhbnQgLS0gaXMgdGhpcyBhY3R1YWxseSBhIG5ldyBwaG9uZSwgb3IgaXMgaXQgYSB3aXJl dGFwPGJyPg0KaW5qZWN0aW9uPyZuYnNwOyBzaG91bGQgaSBhc2sgdGhlIHVzZXIgYWJvdXQgaXQ/ Jm5ic3A7IHNob3VsZCBpIHRha2UgYWN0aW9uPyZuYnNwOyB3aGF0PGJyPg0KY3Rpb24/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkdlbmVyYWxseSwgSSB3 b3VsZG4ndCBleHBlY3QgdGhlbSB0byB0YWtlIGFueSBhY3Rpb24gYXQgYWxsLiBJdCdzIGEgdXNl cidzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+cmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhlIHJp Z2h0IG51bWJlciBvZiBkZXZpY2VzIGFyZSByZWdpc3RlcmVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+dG8g dGhlaXIgYWNjb3VudCwganVzdCBhcyBpdHMgY29tbW9uIGZvciB0aGUgbnVtYmVyIG9mIFdlYiBi cm93c2VyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPm9uZSBoYXMgYXR0YWNoZWQgdG8gb25lcyBHbWFpbCBh Y2NvdW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpUbyBhdm9pZCBVWCB3YXJu aW5nIGZhdGlndWUsIGknbSB3YXJ5IGFib3V0IGludHJvZHVjaW5nIG1vcmUgb2YgdGhlc2U8YnI+ DQpldmVudHMgdGhhbiBhcmUgc3RyaWN0bHkgbmVjZXNzYXJ5IChzY2VuYXJpbyAoYSkgYWJvdmUg cHJvYmFibHk8YnI+DQpyZXByZXNlbnRzIGEgJnF1b3Q7bmVjZXNzYXJ5JnF1b3Q7IGV2ZW50LCBz YWRseSwgYnV0ICZxdW90O2kganVzdCBnb3QgYSBuZXcgcGhvbmUmcXVvdDs8YnI+DQpkb2Vzbid0 IHNlZW0gbmVjZXNzYXJ5KS48YnI+DQo8YnI+DQpBbmQgZmluYWxseSwgd2UgcHJlc3VtYWJseSB3 YW50IGFueSBzb3J0IG9mIGRldmljZSBjaGFuZ2UgdG8gYmU8YnI+DQphdXRob3JpemVkIGZyb20g YW4gYWxyZWFkeS1rbm93biBkZXZpY2UgZm9yIHRoZSBzYW1lIHVzZXIuJm5ic3A7IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGlzIHdhcyBub3QgaW4g ZmFjdCBteSBhc3N1bXB0aW9uLCBmb3IgdGhlIHJlYXNvbiBpbmRpY2F0ZWQgYWJvdmU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4tRWtyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B0F25392001543228B4D22E8E2A73375fbcom_-- From nobody Sat Mar 24 17:06:58 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2E7126BF3 for ; Sat, 24 Mar 2018 17:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH6MspPqa5AY for ; Sat, 24 Mar 2018 17:06:54 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CFB12025C for ; Sat, 24 Mar 2018 17:06:54 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eztBQ-00045m-GG for mls@ietf.org; Sun, 25 Mar 2018 01:06:52 +0100 To: mls@ietf.org References: <87efk9m7e9.fsf@fifthhorseman.net> <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> From: Simon Friedberger Message-ID: Date: Sun, 25 Mar 2018 01:06:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 00:06:56 -0000 Hi Jon and Eric! On 25.03.2018 00:08, Jon Millican wrote: > > I’d like to second Ekr’s points here. To provide a concrete use case, > in Facebook Messenger, we want Secret Conversations to work for a user > as soon as they log in on a new device. This somewhat blurs the > boundary between device loss/recovery and concurrent use as it is used > for both situations; but we don’t want to require existing device to > authorise new devices as – to be perfectly frank – we’re not convinced > that most people would actually do this, and it puts a potential > usability barrier in the way of people using the E2E mode. > Won't this give us e2e encryption but no e2e security against active attackers? If we remove authentication in favor of ux what's to stop an mitm attacker? Eric: > it's that there are use cases in > which users want to add a new device without an existing device being > online, and these are incompatible with type #0 designs. I'm not sure that devices being added is such a common occurence that it would prohibit asking for authorization from a different device. Eric: > Generally, I wouldn't expect them to take any action at all. It's a user's > responsibility to ensure that the right number of devices are registered > to their account, just as its common for the number of Web browsers > one has attached to ones Gmail account. How would a user find out which devices are registered to their account when they don't have to authorize them? And if it can be done, isn't "authorize-on-first-use" more user-friendly than expecting that users will maintain a list of authorized devices, i.e. check at random intervals if the list is still correct? Best Regards, Simon From nobody Sat Mar 24 17:27:52 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74931126C83 for ; Sat, 24 Mar 2018 17:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwqcwuArnVr6 for ; Sat, 24 Mar 2018 17:27:49 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A121812025C for ; Sat, 24 Mar 2018 17:27:49 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id g97-v6so17073335otg.13 for ; Sat, 24 Mar 2018 17:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pwhhz9LC773qdgB3joT/NnMmPgO0P1TTiApYCjN9GgQ=; b=a80CCNGmqUK/DYPK35YhOyQQGep6ndmfa1krhp3et8j+DpenI2XieaunM9fhjprKRD boAJBLKoJ+K/LTKA9QDSVhbA/dg7qz6Muzl957eLtaCJj7c/BK3umWU6UIbzwckBRGbT /Zbu4k1pXAwI7ZLyBo0IQZjB8Mam9j1v/7MAMDSeWQfso7vCegfdWV/vX5DSGDw6NvxN uwZX2QClBy8omc2LpBQ4EOYUxIPwWYXV7Xmkdx9HjVQu99pcGC8erRxRJ5oJidXjWO2Q IFszq+a/Ggn/ozYHpeJq74kCBzleGzVl6eyQVO5eGM5Z2FrJp3klSWP3NK7MJ3eHFUQ3 pVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pwhhz9LC773qdgB3joT/NnMmPgO0P1TTiApYCjN9GgQ=; b=tqyUpDrnnKnPZJZmY1K4veQ08o5ge6WiUlvbM5iM0pgTTbCimWfuDiJhdvQy1LTv0E jFZW/Aq8tYyF2aJYqoxDakdROfLpvwluvx3V5DYpVSbZIieKpK8R4m2ky8WbWDzf5U0T sKrtc5wIQdI6vNczO4T83mXAgwxTzvmUWD8f6G53Wt2kNne5hnzFa8KILAEgLo93V7BK J5N5fsc4MiwT0z/b9/hbNf1RliaHSbcR3EhW/91uznzJeEi4c0UmEhMtD/pAW5jTBSdS 0nejP0Avs5i8DkkqVjD1OteE4w0Kai+bh6j6VSHd5MckC/srzVUM0TYNruGoJwvOKQqg 2xfg== X-Gm-Message-State: AElRT7FmUnQXyDs6l9Mrb/WcVoVSkQZ6rEOBBU15lQMcjEvtik3cLmXc MarpgEyTljI7loNWjJaU8rd5gTb9FbGY68KAT31GmiOl X-Google-Smtp-Source: AG47ELu+xqCUetFQQuZX0t3ntghLzR+IYRNO52OmeBt71WYvNomM1CJ/nemDGSHvAZ/qrfSdm9c736cJ/HyUx51Y+qI= X-Received: by 2002:a9d:26d4:: with SMTP id i20-v6mr19128312otd.214.1521937668755; Sat, 24 Mar 2018 17:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.23.21 with HTTP; Sat, 24 Mar 2018 17:27:08 -0700 (PDT) In-Reply-To: References: <87efk9m7e9.fsf@fifthhorseman.net> <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> From: Eric Rescorla Date: Sun, 25 Mar 2018 00:27:08 +0000 Message-ID: To: Simon Friedberger Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000001de849056831ba50" Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 00:27:51 -0000 --0000000000001de849056831ba50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 25, 2018 at 12:06 AM, Simon Friedberger wrote: > Hi Jon and Eric! > > > On 25.03.2018 00:08, Jon Millican wrote: > > > > I=E2=80=99d like to second Ekr=E2=80=99s points here. To provide a conc= rete use case, > > in Facebook Messenger, we want Secret Conversations to work for a user > > as soon as they log in on a new device. This somewhat blurs the > > boundary between device loss/recovery and concurrent use as it is used > > for both situations; but we don=E2=80=99t want to require existing devi= ce to > > authorise new devices as =E2=80=93 to be perfectly frank =E2=80=93 we= =E2=80=99re not convinced > > that most people would actually do this, and it puts a potential > > usability barrier in the way of people using the E2E mode. > > > > Won't this give us e2e encryption but no e2e security against active > attackers? If we remove authentication in favor of ux what's to stop an > mitm attacker? > Just for clarity, I assume you mean a MITM attacker who controls the authentication server, right Eric: > > it's that there are use cases in > > which users want to add a new device without an existing device being > > online, and these are incompatible with type #0 designs. > > I'm not sure that devices being added is such a common occurence that it > would prohibit asking for authorization from a different device. > OK. I guess Jon and others who run IM services can weigh in here on their experience, but I can tell you about Mozilla's experience in a not-dissimilar setting, namely browser sync. Firefox used to have a system which required interaction between the original device and the one to be enrolled, and we found it to be a very aversive user experience which we eventually abandoned in favor of a more conventional password based design. Eric: > > Generally, I wouldn't expect them to take any action at all. It's a > user's > > responsibility to ensure that the right number of devices are registere= d > > to their account, just as its common for the number of Web browsers > > one has attached to ones Gmail account. > > How would a user find out which devices are registered to their account > when they don't have to authorize them? I've been assuming that systems that wanted to offer strong guarantees some form of key transparency so that users could determine which other devices were registered to their account. > And if it can be done, isn't > "authorize-on-first-use" more user-friendly than expecting that users > will maintain a list of authorized devices, No, I don't believe so. > i.e. check at random > intervals if the list is still correct? > I'm not a UX designer, but this isn't the UX I had in mind. Rather, I was expecting that the app would notify you when a new device was registered. This is already the UX that many Web sites provide for situations when you log in on a new browser (though that's for cases when the threat is password compromise which is why it's safe to offer via the browser or email, rather than in the app)= . -Ekr -Ekr > > > Best Regards, > Simon > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000001de849056831ba50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 25, 2018 at 12:06 AM, Simon Friedberger &= lt;simon.tls@a-ob= en.org> wrote:
Hi Jon and E= ric!


On 25.03.2018 00= :08, Jon Millican wrote:
>
> I=E2=80=99d like to second Ekr=E2=80=99s points here. To provide a con= crete use case,
> in Facebook Messenger, we want Secret Conversations to work for a user=
> as soon as they log in on a new device. This somewhat blurs the
> boundary between device loss/recovery and concurrent use as it is used=
> for both situations; but we don=E2=80=99t want to require existing dev= ice to
> authorise new devices as =E2=80=93 to be perfectly frank =E2=80=93 we= =E2=80=99re not convinced
> that most people would actually do this, and it puts a potential
> usability barrier in the way of people using the E2E mode.
>

Won't this give us e2e encryption but no e2e security against ac= tive
attackers? If we remove authentication in favor of ux what's to stop an=
mitm attacker?

Just for clarity, I assu= me you mean a MITM attacker who controls the authentication server, right



Eric:
> it's that there are use cases in
> which users want to add a new device without an existing device being<= br> > online, and these are incompatible with type #0 designs.

I'm not sure that devices being added is such a common occurence= that it
would prohibit asking for authorization from a different device.

OK. I guess Jon and others who run IM services ca= n weigh in here on their experience, but
I can tell you about Moz= illa's experience in a not-dissimilar setting, namely browser sync.
Firefox used to have a system which required interaction between the= original device
and the one to be enrolled, and we found it to b= e a very aversive user experience which
we eventually abandoned i= n favor of a more conventional password based design.

<= div>

Eric:
> Generally, I wouldn't expect them to take any act= ion at all. It's a user's
> responsibility to ensure that the right number of devices are register= ed
> to their account, just as its common for the number of Web browsers > one has attached to ones Gmail account.

How would a user find out which devices are registered to their acco= unt
when they don't have to authorize them?

I've been assuming that systems that wanted to offer strong guarantees= some
form of key transparency so that users could determine whic= h other devices
were registered to their account.

<= /div>
=C2=A0
And if it can be done= , isn't
"authorize-on-first-use" more user-friendly than expecting that u= sers
will maintain a list of authorized devices,

No, I don't believe so.

=C2=A0
i.e. check at random
intervals if the list is still correct?

I'm not a UX designer, but this isn't the UX I had= in mind. Rather, I was expecting
that the app would notify you w= hen a new device was registered. This is already
the UX that many= Web sites provide for situations when you log in on a new
browse= r (though that's for cases when the threat is password compromise which=
is why it's safe to offer via the browser or email, rather t= han in the app).

-Ekr



=C2=A0

-= Ekr
=C2=A0


Best Regards,
Simon

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

--0000000000001de849056831ba50-- From nobody Sat Mar 24 17:48:57 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F23D127023 for ; Sat, 24 Mar 2018 17:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=goQfXrPc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=QbFTqSFJ 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 jQB7gMFDJvja for ; Sat, 24 Mar 2018 17:48:52 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBC612025C for ; Sat, 24 Mar 2018 17:48:52 -0700 (PDT) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2P0iTBM001835; Sat, 24 Mar 2018 17:48: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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=wwgKhly5bhONRZcbebE9PyqmL4bi0Zcj1BBfSmITCh4=; b=goQfXrPcDCnWhcl/70VFhAN5W+ODyfntvyEMRZc2Ccb0xUShnjP2Zfr4ukj9q1Tft9na 98s7t9vLVu7m0ck/EYaHGNS0nu1XctyFKs9RxzkvkwvtbfQyEgULL6hLijapvpvj3sMj IJbCpZ+NAKr8+vi+Sj5RyZINrdzr4c0OH0Y= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2gwmh58ym7-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Mar 2018 17:48:45 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 24 Mar 2018 17:48:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wwgKhly5bhONRZcbebE9PyqmL4bi0Zcj1BBfSmITCh4=; b=QbFTqSFJHUrtTWHWpiVU/F2l/mXAD3f8FibWneQe0gJYJTuq3Q/ZGiLZE1Cn2vxloc90l2YqjHia3yemTyDVoSvDrc6Hfr0+r4DHn9SLWcf9AS5g9/sKWb2q8JXSCHdkxfnucLKmuBW54EDtVvpk+HM8/7n/p2MRkVLnsV4aw0w= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1576.namprd15.prod.outlook.com (10.172.162.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sun, 25 Mar 2018 00:48:41 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0609.012; Sun, 25 Mar 2018 00:48:41 +0000 From: Jon Millican To: Simon Friedberger , "mls@ietf.org" Thread-Topic: [MLS] multiple devices per user? Thread-Index: AQHTw8Ae2CgUeIFvK0mYODDXyt5r4qPf+1KAgAAHQoCAABBAgIAAC7WA Date: Sun, 25 Mar 2018 00:48:41 +0000 Message-ID: References: <87efk9m7e9.fsf@fifthhorseman.net> <02DC72FA-0C57-4A1B-920D-4B456121CC55@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c092:180::1:a3b9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1576; 7:FeG8YdT0bU1JWEgOeMfbkbzoE72mdfYLxzPGeM6ky13CLpgBEdu97pQDnNq+0GCaTPocO58rG2vXq1PX9EvPX3Mu8xB9bjHiOX2FSz92X7tfWjqzccW+dWygOAkQcgrNlzEjv6bXpoFdXiaPRmKsKuCZPeP93qkH5uURCp0oAhcufUm+TcU4Uh2QqgT1olj3yVUV1D+5Ldltb1WejK2K2JK1x7TWh0cQXS/j4b2ARagP1eQC+IR8p79blIUvptjs; 20:/5eF0g/eahWueW6739rFJQOjFNxt65CeRutZMagSgy89cInF8HiXmPyuztCW6vPgS1FfcxVutARl09vDRyYwvsL/GdzP+W+rIGAcODsV0Ul/jsvQVSzvEEPDh1SL2b4zlIMDTi7aJQEv+Yi3nw5zZvahpxYkcEjYIEWAA9dunTc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d2719704-ebaa-401b-8de1-08d591ea27c4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1576; x-ms-traffictypediagnostic: CY4PR15MB1576: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(209352067349851)(192374486261705)(81227570615382); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231221)(11241501184)(944501327)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR15MB1576; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1576; x-forefront-prvs: 0622A98CD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(39380400002)(396003)(376002)(366004)(199004)(189003)(68736007)(97736004)(99286004)(83716003)(59450400001)(76176011)(102836004)(6506007)(7736002)(53546011)(186003)(2616005)(110136005)(105586002)(106356001)(11346002)(446003)(575784001)(86362001)(46003)(3280700002)(2900100001)(3660700001)(25786009)(53936002)(8676002)(966005)(305945005)(478600001)(5660300001)(93886005)(82746002)(6306002)(81156014)(2501003)(81166006)(5250100002)(229853002)(6486002)(2906002)(6512007)(6246003)(14454004)(33656002)(6436002)(5890100001)(8936002)(6116002)(36756003)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1576; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LRjVcxgeLPzQqOj2JI6Bn5WwuaBWbB/Xhs5+MkkqyyOew+kP2MPDYwgZWREPQfGbKr+sBdG6PpSrrDD3fxMzevg54JaNaJJk6a5qx2VffxnCoA+VE08ybcGeZYpacyCbGPuBtYEgLGU1kDA/xVhvY05wklZHiogGsU51ANFyj0jKwgC7eFAqzyLvlzC39yazls6GRNHKR38TpXzKmjLNU+yZnAnndAtwd+kHEWg6ZElybBkNggfnjgA6mvwJCvvD8+7G75YaVgSWq7oSVALnIGbvm0ZGN6o+ilejlDIkH1Kr3W8uXtxnGGzs5IcGMe5ZI924IdpxGYAVMgWJswwu0Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6738A7002A719D4DB7BB184F2CFE8DD5@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d2719704-ebaa-401b-8de1-08d591ea27c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 00:48:41.7735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1576 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-24_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 00:48:55 -0000 SGkgU2ltb24hDQoNCiAgICBXb24ndCB0aGlzIGdpdmUgdXMgZTJlIGVuY3J5cHRpb24gYnV0IG5v IGUyZSBzZWN1cml0eSBhZ2FpbnN0IGFjdGl2ZQ0KICAgIGF0dGFja2Vycz8gSWYgd2UgcmVtb3Zl IGF1dGhlbnRpY2F0aW9uIGluIGZhdm9yIG9mIHV4IHdoYXQncyB0byBzdG9wIGFuDQogICAgbWl0 bSBhdHRhY2tlcj8NCg0KSSB0aGluayB0aGlzIGlzIGxpa2VseSBhcHBsaWNhdGlvbi1zcGVjaWZp YywgYnV0IGluIG91ciBjYXNlIHdlIHN1cmZhY2UgYWxsIGRldmljZSBsaXN0IGNoYW5nZXMgd2l0 aGluIEUyRSB0aHJlYWRzLCBhbmQgeW91IGNhbiBsb29rIGF0IHRoZSBzcGVjaWZpYyBkZXZpY2Ug cHVibGljIGtleXMgaWYgd2lzaC4gSWYgeW91IHNlZSB0aGF0IEkgaGF2ZSBhIG5ldyBkZXZpY2Us IHlvdSBjYW4gdGh1cyAtIGluIHRoZW9yeSAtIGFzayBtZSBvdXQgb2YgYmFuZCB3aGV0aGVyIHRo ZSBrZXkgaXMgbGVnaXRpbWF0ZS4gVGhlIHJlbGV2YW50IHBhcnQgb2Ygb3VyIHRocmVhdCBtb2Rl bCBoZXJlIGlzICJ5b3Ugc2hvdWxkIGtub3cgd2hhdCBlbmRwb2ludHMgeW91J3JlIHNlbmRpbmcg bWVzc2FnZXMgdG8gYmVmb3JlIHlvdSBzZW5kIHRoZSBtZXNzYWdlIiwgc28gdGhpcyBmdWxmaWxz IHRoYXQgcmVxdWlyZW1lbnQuDQoNCiAgICBJJ20gbm90IHN1cmUgdGhhdCBkZXZpY2VzIGJlaW5n IGFkZGVkIGlzIHN1Y2ggYSBjb21tb24gb2NjdXJlbmNlIHRoYXQgaXQNCiAgICB3b3VsZCBwcm9o aWJpdCBhc2tpbmcgZm9yIGF1dGhvcml6YXRpb24gZnJvbSBhIGRpZmZlcmVudCBkZXZpY2UuDQoN CkluIG91ciB1c2UgY2FzZSwgdGhpcyBpcyBjb21tb24uIFdoZW5ldmVyIHNvbWVib2R5IGxvZ3Mg aW4gb24gYSBuZXcgZGV2aWNlLCB0aGVyZSdzIGEgc3Ryb25nIGNoYW5jZSB0aGF0IHRoZXkgZG9u J3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIHByZXZpb3VzIG9uZSBhdCB0aGUgdGltZSAtIGFuZCB3b24n dCB3YW50IHRvIGJlIGJsb2NrZWQgZnJvbSB1c2luZyBNZXNzZW5nZXIgdW50aWwgdGhleSBjYW4g YXV0aG9yaXNlIHRoZSBuZXcgZGV2aWNlIC0gcGFydGljdWxhcmx5IGlmIGl0J3MgYSByZXBsYWNl bWVudCBwaG9uZSBmb3IgZXhhbXBsZS4gQXMgRmFjZWJvb2sgTWVzc2VuZ2VyIGl0c2VsZiBpcyBu b3QgYW4gRTJFIGFwcCBpbiB0aGUgZ2VuZXJhbCBjYXNlLCB3ZSB3b3VsZG4ndCB3YW50IHRvIGFk ZCBhZGRpdGlvbmFsIGJhcnJpZXJzIHRoYXQgZGlzY291cmFnZSBwZW9wbGUgZnJvbSB1c2luZyBT ZWNyZXQgQ29udmVyc2F0aW9ucy4NCiANCiAgICBIb3cgd291bGQgYSB1c2VyIGZpbmQgb3V0IHdo aWNoIGRldmljZXMgYXJlIHJlZ2lzdGVyZWQgdG8gdGhlaXIgYWNjb3VudA0KICAgIHdoZW4gdGhl eSBkb24ndCBoYXZlIHRvIGF1dGhvcml6ZSB0aGVtPyBBbmQgaWYgaXQgY2FuIGJlIGRvbmUsIGlz bid0DQogICAgImF1dGhvcml6ZS1vbi1maXJzdC11c2UiIG1vcmUgdXNlci1mcmllbmRseSB0aGFu IGV4cGVjdGluZyB0aGF0IHVzZXJzDQogICAgd2lsbCBtYWludGFpbiBhIGxpc3Qgb2YgYXV0aG9y aXplZCBkZXZpY2VzLCBpLmUuIGNoZWNrIGF0IHJhbmRvbQ0KICAgIGludGVydmFscyBpZiB0aGUg bGlzdCBpcyBzdGlsbCBjb3JyZWN0Pw0KDQpJIHRoaW5rIEkgYWRkcmVzc2VkIHRoaXMgYWJvdmUs IGJ1dCB3ZSBsZXQgcGVvcGxlIGtub3cgd2hlbiBuZXcgZGV2aWNlcyBhcmUgYWRkZWQgdG8gdGhl aXIgYWNjb3VudC4gVGhvc2Ugd2hvIHdpc2ggdG8gY2FuIGdvIGNoZWNrIHRoZSBsaXN0IG9mIGRl dmljZXMgb24gdGhlaXIgYWNjb3VudCBhdCB0aGlzIHBvaW50Lg0KDQpIb3BlIHRoYXQgYWxsIG1h a2VzIHNlbnNlLA0KSm9uDQoNCu+7v09uIDI1LzAzLzIwMTgsIDAwOjA3LCAiTUxTIG9uIGJlaGFs ZiBvZiBTaW1vbiBGcmllZGJlcmdlciIgPG1scy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBzaW1vbi50bHNAYS1vYmVuLm9yZz4gd3JvdGU6DQoNCiAgICBIaSBKb24gYW5kIEVyaWMhDQog ICAgDQogICAgDQogICAgT24gMjUuMDMuMjAxOCAwMDowOCwgSm9uIE1pbGxpY2FuIHdyb3RlOg0K ICAgID4NCiAgICA+IEnigJlkIGxpa2UgdG8gc2Vjb25kIEVrcuKAmXMgcG9pbnRzIGhlcmUuIFRv IHByb3ZpZGUgYSBjb25jcmV0ZSB1c2UgY2FzZSwNCiAgICA+IGluIEZhY2Vib29rIE1lc3Nlbmdl ciwgd2Ugd2FudCBTZWNyZXQgQ29udmVyc2F0aW9ucyB0byB3b3JrIGZvciBhIHVzZXINCiAgICA+ IGFzIHNvb24gYXMgdGhleSBsb2cgaW4gb24gYSBuZXcgZGV2aWNlLiBUaGlzIHNvbWV3aGF0IGJs dXJzIHRoZQ0KICAgID4gYm91bmRhcnkgYmV0d2VlbiBkZXZpY2UgbG9zcy9yZWNvdmVyeSBhbmQg Y29uY3VycmVudCB1c2UgYXMgaXQgaXMgdXNlZA0KICAgID4gZm9yIGJvdGggc2l0dWF0aW9uczsg YnV0IHdlIGRvbuKAmXQgd2FudCB0byByZXF1aXJlIGV4aXN0aW5nIGRldmljZSB0bw0KICAgID4g YXV0aG9yaXNlIG5ldyBkZXZpY2VzIGFzIOKAkyB0byBiZSBwZXJmZWN0bHkgZnJhbmsg4oCTIHdl 4oCZcmUgbm90IGNvbnZpbmNlZA0KICAgID4gdGhhdCBtb3N0IHBlb3BsZSB3b3VsZCBhY3R1YWxs eSBkbyB0aGlzLCBhbmQgaXQgcHV0cyBhIHBvdGVudGlhbA0KICAgID4gdXNhYmlsaXR5IGJhcnJp ZXIgaW4gdGhlIHdheSBvZiBwZW9wbGUgdXNpbmcgdGhlIEUyRSBtb2RlLg0KICAgID4NCiAgICAN CiAgICBXb24ndCB0aGlzIGdpdmUgdXMgZTJlIGVuY3J5cHRpb24gYnV0IG5vIGUyZSBzZWN1cml0 eSBhZ2FpbnN0IGFjdGl2ZQ0KICAgIGF0dGFja2Vycz8gSWYgd2UgcmVtb3ZlIGF1dGhlbnRpY2F0 aW9uIGluIGZhdm9yIG9mIHV4IHdoYXQncyB0byBzdG9wIGFuDQogICAgbWl0bSBhdHRhY2tlcj8N CiAgICANCiAgICANCiAgICBFcmljOg0KICAgID4gaXQncyB0aGF0IHRoZXJlIGFyZSB1c2UgY2Fz ZXMgaW4NCiAgICA+IHdoaWNoIHVzZXJzIHdhbnQgdG8gYWRkIGEgbmV3IGRldmljZSB3aXRob3V0 IGFuIGV4aXN0aW5nIGRldmljZSBiZWluZw0KICAgID4gb25saW5lLCBhbmQgdGhlc2UgYXJlIGlu Y29tcGF0aWJsZSB3aXRoIHR5cGUgIzAgZGVzaWducy4NCiAgICANCiAgICBJJ20gbm90IHN1cmUg dGhhdCBkZXZpY2VzIGJlaW5nIGFkZGVkIGlzIHN1Y2ggYSBjb21tb24gb2NjdXJlbmNlIHRoYXQg aXQNCiAgICB3b3VsZCBwcm9oaWJpdCBhc2tpbmcgZm9yIGF1dGhvcml6YXRpb24gZnJvbSBhIGRp ZmZlcmVudCBkZXZpY2UuDQogICAgDQogICAgDQogICAgRXJpYzoNCiAgICA+IEdlbmVyYWxseSwg SSB3b3VsZG4ndCBleHBlY3QgdGhlbSB0byB0YWtlIGFueSBhY3Rpb24gYXQgYWxsLiBJdCdzIGEg dXNlcidzDQogICAgPiByZXNwb25zaWJpbGl0eSB0byBlbnN1cmUgdGhhdCB0aGUgcmlnaHQgbnVt YmVyIG9mIGRldmljZXMgYXJlIHJlZ2lzdGVyZWQNCiAgICA+IHRvIHRoZWlyIGFjY291bnQsIGp1 c3QgYXMgaXRzIGNvbW1vbiBmb3IgdGhlIG51bWJlciBvZiBXZWIgYnJvd3NlcnMNCiAgICA+IG9u ZSBoYXMgYXR0YWNoZWQgdG8gb25lcyBHbWFpbCBhY2NvdW50Lg0KICAgIA0KICAgIEhvdyB3b3Vs ZCBhIHVzZXIgZmluZCBvdXQgd2hpY2ggZGV2aWNlcyBhcmUgcmVnaXN0ZXJlZCB0byB0aGVpciBh Y2NvdW50DQogICAgd2hlbiB0aGV5IGRvbid0IGhhdmUgdG8gYXV0aG9yaXplIHRoZW0/IEFuZCBp ZiBpdCBjYW4gYmUgZG9uZSwgaXNuJ3QNCiAgICAiYXV0aG9yaXplLW9uLWZpcnN0LXVzZSIgbW9y ZSB1c2VyLWZyaWVuZGx5IHRoYW4gZXhwZWN0aW5nIHRoYXQgdXNlcnMNCiAgICB3aWxsIG1haW50 YWluIGEgbGlzdCBvZiBhdXRob3JpemVkIGRldmljZXMsIGkuZS4gY2hlY2sgYXQgcmFuZG9tDQog ICAgaW50ZXJ2YWxzIGlmIHRoZSBsaXN0IGlzIHN0aWxsIGNvcnJlY3Q/DQogICAgDQogICAgDQog ICAgQmVzdCBSZWdhcmRzLA0KICAgIFNpbW9uDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBNTFMgbWFpbGluZyBsaXN0DQogICAg TUxTQGlldGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19tbHMmZD1Ed0lHYVEm Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9TTBDVkVKeWRCVlVYX2J2RXFNYTg0USZtPXlkUGdC c2RiZ1NGWVVGd2RKbS02djkyVzhqZm1SWDBiTENXb3RpWlVWNzQmcz10QUtLM2VvVjNmYUQ2aXNJ eHU4Qm9yUGRuTWY2dk84bTNqQTlETXM2bzk0JmU9DQogICAgDQoNCg== From nobody Sun Mar 25 03:53:50 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A25127867 for ; Sun, 25 Mar 2018 03:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoFvtyW17ro5 for ; Sun, 25 Mar 2018 03:53:47 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E993B127599 for ; Sun, 25 Mar 2018 03:53:46 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f03HQ-0007Sh-51 for mls@ietf.org; Sun, 25 Mar 2018 12:53:44 +0200 References: To: mls@ietf.org From: Simon Friedberger X-Forwarded-Message-Id: Message-ID: <77e637fe-635f-b696-879d-e99add067b03@a-oben.org> Date: Sun, 25 Mar 2018 12:53:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MLS] Fwd: Re: multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 10:53:48 -0000 (Copy to the list.) Hi Eric! > > Eric: > > it's that there are use cases in > > which users want to add a new device without an existing device > being > > online, and these are incompatible with type #0 designs. > > I'm not sure that devices being added is such a common occurence > that it > would prohibit asking for authorization from a different device. > > > OK. I guess Jon and others who run IM services can weigh in here on > their experience, but > I can tell you about Mozilla's experience in a not-dissimilar setting, > namely browser sync. > Firefox used to have a system which required interaction between the > original device > and the one to be enrolled, and we found it to be a very aversive user > experience which > we eventually abandoned in favor of a more conventional password based > design. > Indeed that sounds much better. So how does this work? The user encrypts their data with a password derived key and you use some form of challenge response for authentication so you never get the password? So for MLS this would translate to the service provider holding password encrypted packets with pre-approved authentication keys from a known good device? Best Regards, Simon From nobody Sun Mar 25 03:54:53 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9A12785F for ; Sun, 25 Mar 2018 03:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGRgGyVSh_jq for ; Sun, 25 Mar 2018 03:54:50 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E8D127599 for ; Sun, 25 Mar 2018 03:54:50 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f03IW-0003Ky-Cp for mls@ietf.org; Sun, 25 Mar 2018 12:54:48 +0200 References: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de> To: mls@ietf.org From: Simon Friedberger X-Forwarded-Message-Id: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de> Message-ID: <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org> Date: Sun, 25 Mar 2018 12:54:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [MLS] Fwd: Re: multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 10:54:51 -0000 (Resent because I had the wrong sender address.) Hi Jon! On 25.03.2018 01:48, Jon Millican wrote: > I think this is likely application-specific, but in our case we surface all device list changes within E2E threads, and you can look at the specific device public keys if wish. If you see that I have a new device, you can thus - in theory - ask me out of band whether the key is legitimate. The relevant part of our threat model here is "you should know what endpoints you're sending messages to before you send the message", so this fulfils that requirement. I think having the partners deal with new devices is the wrong approach. They probably don't know if a user has new devices so adding trust to devices should be handled by the users with the devices. > In our use case, this is common. Whenever somebody logs in on a new device, there's a strong chance that they don't have access to the previous one at the time - and won't want to be blocked from using Messenger until they can authorise the new device - particularly if it's a replacement phone for example. As Facebook Messenger itself is not an E2E app in the general case, we wouldn't want to add additional barriers that discourage people from using Secret Conversations. I think the cases of replacing devices and adding them should be treated differently. In the latter case trust has already been established and can be transferred. In the first case, which is the case you are concerned with, there is no trust and it should be an implementation detail to highlight this to the user so the protocol should not make them equivalent. > I think I addressed this above, but we let people know when new devices are added to their account. Those who wish to can go check the list of devices on their account at this point. But that only works with some form of key transparency, right? Otherwise the device list can easily be manipulated. Best Regards, Simon From nobody Sun Mar 25 05:23:53 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921A1241F8 for ; Sun, 25 Mar 2018 05:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XppWajcy8ggW for ; Sun, 25 Mar 2018 05:23:50 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D151201FA for ; Sun, 25 Mar 2018 05:23:50 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id n40-v6so951678otd.3 for ; Sun, 25 Mar 2018 05:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lzf7Ib+a6r0qJFOnX2d3XhRdkEEnSu8bss3LRQCLqSY=; b=MHOlZZZ/sS5pJaG7tMwG/OBU6kGTBRWbd7szaB9yL3A/DQ3ZgWFVuGAkoOpFC9OIJ1 1ww/dmCvfEImUHODApmEFg8tS7IHGksbgFZWzQ2p5ufn79SbumubLp012MK3E5KJAzbs RQY+LLTuGfWZ6zIiTP49bNosrDPubXzWNURVyyr26W9evJyU073Z8aHLerCPKZE62dvg FSElyyySyTvtaySPzi4ECBCw9bSVPSTUwvc087s4rmzyqjgSmyVZiZvNqGZvc2dGzo/Y SaTmDwRCtbPpST73nbd6caavm4WAu5Am8+4frrNCiXKmMiPB/eEDA7PnLenFFGXvn6UJ LU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lzf7Ib+a6r0qJFOnX2d3XhRdkEEnSu8bss3LRQCLqSY=; b=q1AXGyYuowOOvySF57oTG1pE3pBbXAr8QociB32zAkW2V6o+ut0L7L354h0PdbOAiZ GSMfUlXnk781ra4x3ki1PMP9EP+e2LPixdeqgmsMtwZhYmE6eDWh5f3X148scYGakQHu KsZJkgdSsjnfJ8nj5Fo8M90qnxeURPWK9EsDEvTDpN7Glq6lMEyoE+pQhxTGFDjbHIv4 QGufeVFqxYCucFJ4hdMeYFtt61qYvXr+o9QU2Hsg9SVdFu0580iU0DSAzT1cbb4ZPWNy L+AXDCStwPVIhz85484PSb1cn+XNCT4dAkMtcAvdoV9nt6XZiMDfIiIUn/g4qMJ+N9bM IKrQ== X-Gm-Message-State: AElRT7EKTl2mg1+IuCtUi6aA4IXzoVxnyG4OTKkk1ZGjfKymRnBsV5LT pq7BqBXSdAKUbSo67n16WDFNLh+kg54z0RZW/PrTRA== X-Google-Smtp-Source: AG47ELt/42D68n3GMO0LPTagqKf9QnhD1LtG649LJJUIT/z4HWKQ0R5+Biz/Pua+WLKapIAhGoGmOuiyM4anjxO/gjM= X-Received: by 2002:a9d:e06:: with SMTP id c6-v6mr18553952otc.371.1521980629214; Sun, 25 Mar 2018 05:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.23.21 with HTTP; Sun, 25 Mar 2018 05:23:08 -0700 (PDT) In-Reply-To: <77e637fe-635f-b696-879d-e99add067b03@a-oben.org> References: <77e637fe-635f-b696-879d-e99add067b03@a-oben.org> From: Eric Rescorla Date: Sun, 25 Mar 2018 05:23:08 -0700 Message-ID: To: Simon Friedberger Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="000000000000c2784c05683bba4e" Archived-At: Subject: Re: [MLS] Fwd: Re: multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 12:23:52 -0000 --000000000000c2784c05683bba4e Content-Type: text/plain; charset="UTF-8" On Sun, Mar 25, 2018 at 3:53 AM, Simon Friedberger wrote: > (Copy to the list.) > > Hi Eric! > > > > > > Eric: > > > it's that there are use cases in > > > which users want to add a new device without an existing device > > being > > > online, and these are incompatible with type #0 designs. > > > > I'm not sure that devices being added is such a common occurence > > that it > > would prohibit asking for authorization from a different device. > > > > > > OK. I guess Jon and others who run IM services can weigh in here on > > their experience, but > > I can tell you about Mozilla's experience in a not-dissimilar setting, > > namely browser sync. > > Firefox used to have a system which required interaction between the > > original device > > and the one to be enrolled, and we found it to be a very aversive user > > experience which > > we eventually abandoned in favor of a more conventional password based > > design. > > > Indeed that sounds much better. So how does this work? The user encrypts > their data with a password derived key and you use some form of > challenge response for authentication so you never get the password? > This is documented at: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol So for MLS this would translate to the service provider holding password > encrypted packets with pre-approved authentication keys from a known > good device? > Well, I wasn't suggesting we adopt the Firefox protocol, merely that the UX requirements of a scheme which required key transfer were not good. -Ekr > > Best Regards, > Simon > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --000000000000c2784c05683bba4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 25, 2018 at 3:53 AM, Simon Friedberger &l= t;simon.tls@a-obe= n.org> wrote:
(Copy to the list.)

Hi Eric!


>
>=C2=A0 =C2=A0 =C2=A0Eric:
>=C2=A0 =C2=A0 =C2=A0> it's that there are use cases in
>=C2=A0 =C2=A0 =C2=A0> which users want to add a new device without a= n existing device
>=C2=A0 =C2=A0 =C2=A0being
>=C2=A0 =C2=A0 =C2=A0> online, and these are incompatible with type #= 0 designs.
>
>=C2=A0 =C2=A0 =C2=A0I'm not sure that devices being added is such a= common occurence
>=C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0would prohibit asking for authorization from a diff= erent device.
>
>
> OK. I guess Jon and others who run IM services can weigh in here on > their experience, but
> I can tell you about Mozilla's experience in a not-dissimilar sett= ing,
> namely browser sync.
> Firefox used to have a system which required interaction between the > original device
> and the one to be enrolled, and we found it to be a very aversive user=
> experience which
> we eventually abandoned in favor of a more conventional password based=
> design.
>
Indeed that sounds much better. So how does this work? The user encrypts their data with a password derived key and you use some form of
challenge response for authentication so you never get the password?

This is documented at:
= = https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol


So for MLS this would translate to the service provider holding password encrypted packets with pre-approved authentication keys from a known
good device?

Well, I wasn&#= 39;t suggesting we adopt the Firefox protocol, merely that the UX
requirements of a scheme which required key transfer were not good.
<= div>
-Ekr



Best Regards,
Simon

___________= ____________________________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls

--000000000000c2784c05683bba4e-- From nobody Sun Mar 25 06:21:50 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C5A1250B8 for ; Sun, 25 Mar 2018 06:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ftpORkgT; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HjEsduME 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 UUu3CsQdEm1X for ; Sun, 25 Mar 2018 06:21:47 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DAD1205D3 for ; Sun, 25 Mar 2018 06:21:47 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w2PDJRWx023216; Sun, 25 Mar 2018 06:21:40 -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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=wGjLnelOf+apbBMvqPzwXhsSlbW2vDPc3MTpIMBYrQM=; b=ftpORkgTJ7oXqU/4GlIcEOe8ErE96kZuS5rD3L27iq3aEFT5gxvleyJzzHjOU64kCTzP paRyKKjSMYIlaCHr135AC0BEVjm1OZGypRtJ+T94y0R3ecFCNt0vBzPJWeQf3T0amxoZ z76FCknX+/Wa6B/v/wOr+1mxLRtv1aD56IU= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2gwj5ysum3-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Mar 2018 06:21:40 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 25 Mar 2018 09:21:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wGjLnelOf+apbBMvqPzwXhsSlbW2vDPc3MTpIMBYrQM=; b=HjEsduMEBmfxhDuBWKTCGDqfr3DTc1t4pk7jMt2TmAR12Qy7wTwMjM1akGpIaVLz+v4F4nXSW6M5oD5/bO7i1fI7Kz7R4vpP3DeKK6awoM5L7oFv9JNzQzrQAWFEioJez8NJEE5ocpB+JQY4dJK7ED2aLwfETh9BJF0CeH8/VJk= Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by CY4PR15MB1942.namprd15.prod.outlook.com (10.172.180.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Sun, 25 Mar 2018 13:21:37 +0000 Received: from CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659]) by CY4PR15MB1751.namprd15.prod.outlook.com ([fe80::c4ba:acd7:6982:b659%17]) with mapi id 15.20.0609.012; Sun, 25 Mar 2018 13:21:37 +0000 From: Jon Millican To: Simon Friedberger , "mls@ietf.org" Thread-Topic: [MLS] Fwd: Re: multiple devices per user? Thread-Index: AQHTxCe5vIFKcpQrPkCN3YGVCqXYYKPhANuA Date: Sun, 25 Mar 2018 13:21:37 +0000 Message-ID: <0273A6A6-A491-4DC2-9B07-8B048EE4B537@fb.com> References: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de> <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org> In-Reply-To: <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.39.102.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1942; 7:eH+TF18qLdH0tgX+R2aU0PNhRCmx9mmto0jQ+duCCE7v4O3rBmUPB42XyMsbYJvwwMMgRPQMDM4o1G+6XfTcl2JLnLMg9SCw7lo4b0hJGMIiKZFBF8Rs0njcxo2Pbfo/wCxK0KgV5zr5hcp4sm2/TTYLMgYw23JfDBuQMIQLmrADLHujTgQ7+ldEPxCbJp9/8KZ1WcdRLHqaz1r152mS4O9t9MGRuEl1uVoyCoRHuTXPedZkvfvhTg65VrakTU6G; 20:eBLAszTjZkWKdvlLBPFAPm8oA4fdL1+ZfOU+dXsubYzpSWBSCa/37BJXppjC8Wh4VwyxFeAIrJFS7iWyUj24UTGaoMpRAZpBM5hw+HzjweptnUUDB/j79PLnpF6FL4BK7CieEZwsaXnDk5KE2iSBZC/mxN2/bLK8AY8UOHod4Wo= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: da8930f0-5953-4e31-8b66-08d5925356b2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR15MB1942; x-ms-traffictypediagnostic: CY4PR15MB1942: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(81227570615382); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(11241501184)(944501327)(52105095)(93006095)(93001095)(3002001)(10201501046)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR15MB1942; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1942; x-forefront-prvs: 0622A98CD5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39860400002)(39380400002)(396003)(51444003)(189003)(199004)(51914003)(99286004)(76176011)(110136005)(8676002)(59450400001)(8936002)(6506007)(81166006)(81156014)(2900100001)(106356001)(102836004)(14454004)(55236004)(26005)(186003)(966005)(83716003)(3280700002)(105586002)(478600001)(3660700001)(2616005)(2906002)(446003)(11346002)(36756003)(68736007)(5250100002)(82746002)(66066001)(3846002)(6306002)(6512007)(229853002)(2501003)(25786009)(316002)(86362001)(575784001)(6116002)(575854001)(53936002)(5660300001)(97736004)(7736002)(53546011)(33656002)(6486002)(6246003)(6436002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1942; H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OqMby6n0Y7zqD1ZepuSq8tqbByB5I7SUGhqQz8sp5vAjxTKQ0dT3ufZDXl9A4aQj29ufVy8/hhATZG5LGwxOCdpd4ofdJHO6z+cCKjHWveWIWVfosDxxAHdRR1VDcHQXhoI9zZq1xuVArMOPJywIFu+t2VdFYNyNBQDToderbKAMWkCcyIys0pZ6+nif63cpuhInhj2MwuQSQR1maNAX823GS4LAzTNcHF9YFwxVThwj7xDQa7KgLzJgPp4bDMcgeB+hFTjCbfsHshlh9yVKIRjJ6Zw0mIpPJGSj6qEUoHt946vIjlhkmzK7JS4FMUzIhZglHkdKYSZ525XDzJRirQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <49209C99D609C14A93EB7B0A19C0FFA4@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: da8930f0-5953-4e31-8b66-08d5925356b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2018 13:21:37.5869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1942 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-25_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: Subject: Re: [MLS] Fwd: Re: multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 13:21:49 -0000 SGkgU2ltb24sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBJIHVuZGVyc3RhbmQgeW91ciBw b2ludCBvZiB2aWV3LCBhbmQgaGF2ZSBhdCB0aW1lcyBhZHZvY2F0ZWQgZm9yIG1hbnkgb2YgdGhl IHNhbWUgc3VnZ2VzdGlvbnMuIEhvcGVmdWxseSB0aGUgY29udGV4dCBiZWxvdyB3aWxsIGhlbHAg dG8gY2xhcmlmeSBvdXIgZGVzaWduIGNob2ljZXMuDQoNCiAgICBJIHRoaW5rIGhhdmluZyB0aGUg cGFydG5lcnMgZGVhbCB3aXRoIG5ldyBkZXZpY2VzIGlzIHRoZSB3cm9uZyBhcHByb2FjaC4NCiAg ICBUaGV5IHByb2JhYmx5IGRvbid0IGtub3cgaWYgYSB1c2VyIGhhcyBuZXcgZGV2aWNlcyBzbyBh ZGRpbmcgdHJ1c3QgdG8NCiAgICBkZXZpY2VzIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSB1c2Vy cyB3aXRoIHRoZSBkZXZpY2VzLg0KDQpBcyBJIHNheSwgdGhpcyBpcyBhIHNwZWNpZmljIHVzZSBj YXNlIGluIHdoaWNoIHdlIHJlcXVpcmUgZGV2aWNlcyB0byB3b3JrIGltbWVkaWF0ZWx5IG9uIGxv ZyBpbi4gSSBhYnNvbHV0ZWx5IGFjY2VwdCB0aGF0IGNvbXBhcmluZyBsb25nIHN0cmluZ3Mgb2Yg cmFuZG9tIGNoYXJhY3RlcnMgZm9yIGFsbCBkZXZpY2UgY2hhbmdlcyBpcyBhIGRpZmZpY3VsdCBh c2s7IGJ1dCB1bmZvcnR1bmF0ZWx5IGluIHRoaXMgc3BlY2lmaWMgY2FzZSwgcmVxdWlyaW5nIHVz ZXJzIHRvIGV4cGxpY2l0bHkgZW5yb2wgYSBkZXZpY2UgZnJvbSBhbm90aGVyIHdhc24ndCBmZWFz aWJsZS4NCg0KICAgIEkgdGhpbmsgdGhlIGNhc2VzIG9mIHJlcGxhY2luZyBkZXZpY2VzIGFuZCBh ZGRpbmcgdGhlbSBzaG91bGQgYmUgdHJlYXRlZA0KICAgIGRpZmZlcmVudGx5LiBJbiB0aGUgbGF0 dGVyIGNhc2UgdHJ1c3QgaGFzIGFscmVhZHkgYmVlbiBlc3RhYmxpc2hlZCBhbmQNCiAgICBjYW4g YmUgdHJhbnNmZXJyZWQuIEluIHRoZSBmaXJzdCBjYXNlLCB3aGljaCBpcyB0aGUgY2FzZSB5b3Ug YXJlDQogICAgY29uY2VybmVkIHdpdGgsIHRoZXJlIGlzIG5vIHRydXN0IGFuZCBpdCBzaG91bGQg YmUgYW4gaW1wbGVtZW50YXRpb24NCiAgICBkZXRhaWwgdG8gaGlnaGxpZ2h0IHRoaXMgdG8gdGhl IHVzZXIgc28gdGhlIHByb3RvY29sIHNob3VsZCBub3QgbWFrZQ0KICAgIHRoZW0gZXF1aXZhbGVu dC4NCg0KVGhpcyBjdXRzIHRvIHRoZSByZWFzb24gd2h5IGV4cGxpY2l0bHkgZW5yb2xsaW5nIGRl dmljZXMgZnJvbSB0cnVzdGVkIGRldmljZXMgd291bGQgYmUgZGlmZmljdWx0IGZvciB1cy4gSXQn cyBhIGNvbW1vbiBzaXR1YXRpb24gaW4gd2hpY2ggdGhlIG9yaWdpbmFsIGRldmljZSBpcyBubyBs b25nZXIgYXZhaWxhYmxlIGZvciB3aGF0ZXZlciByZWFzb24gKGxvc3QsIHN0b2xlbiwgYnJva2Vu LCBzb2xkLCBldGMpLCBzbyBuZXcgZGV2aWNlcyB0aGF0IHBlb3BsZSBsb2cgaW4gdG8gc2ltcGx5 IHdvdWxkbid0IGJlIGFibGUgdG8gdXNlIFNlY3JldCBDb252ZXJzYXRpb25zIHdpdGhvdXQgY2hv b3NpbmcgdG8gZXhwbGljaXRseSBlbmFibGUgdGhlIG5ldyBkZXZpY2UgZm9yIGl0LiBOb3Qgb25s eSBkb2VzIHRoaXMgbWFrZSB0aGluZ3MgaGFyZGVyIGZvciBwZW9wbGUgd2hvIGV4cGxpY2l0bHkg cGxhbiB0byBzZW5kIGFuIEUyRSBtZXNzYWdlLCBidXQgaXQgbWVhbnMgdGhhdCBwZW9wbGUgd2hv IGRvbid0IGtub3cgYWJvdXQgdGhlIEUyRSBtb2RlIHdpbGwgc2ltcGx5IGJlY29tZSBpbmFjY2Vz c2libGUgb3ZlciB0aW1lIGFzIHRoZXkgdXBncmFkZSBkZXZpY2VzOyBhbmQgdGhvc2UgcGVvcGxl IHdobyBkbyBleHBsaWNpdGx5IHdhbnQgdG8gdXNlIFNlY3JldCBDb252ZXJzYXRpb25zIHdvbid0 IGJlIGFibGUgdG8gcmVhY2ggdGhlaXIgZnJpZW5kcyB3aG8gYXJlIHVuYXdhcmUgb2YvdW5pbnRl cmVzdGVkIGluIHRoZSBmZWF0dXJlLiBJJ20gbm90IHNwZWFraW5nIGluIGh5cG90aGV0aWNhbHMg aGVyZTsgdGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgU2VjcmV0IENvbnZlcnNhdGlvbnMgd29ya2Vk IGluIGV4YWN0bHkgdGhpcyB3YXk6IGl0IHdhcyBzaW5nbGUtZGV2aWNlIHBlciB1c2VyLCBzbyBp ZiB5b3UgcmVwbGFjZWQgeW91ciBwaG9uZSwgeW91IHdvdWxkIGhhdmUgdG8gZXhwbGljaXRseSBl bmFibGUgU2VjcmV0IENvbnZlcnNhdGlvbnMgb24gdGhlIG5ldyBkZXZpY2UsIG90aGVyd2lzZSB0 aGUgZW5yb2xsZWQgZGV2aWNlIGZvciB5b3VyIGFjY291bnQgd291bGQgcmVtYWluIGFzIHRoZSBv bmUgdGhhdCB3YXMgZW5hYmxlZCB3aGVuIHdlIG9yaWdpbmFsbHkgcm9sbGVkIG91dCB0aGUgZmVh dHVyZS4gT3ZlciB0aW1lLCBpdCB3YXMgZWFzaWx5IG9ic2VydmFibGUgdGhhdCBwZW9wbGUgd291 bGQgYmVjb21lIGluYWNjZXNzaWJsZSB2aWEgdGhlIGZlYXR1cmUsIHdoaWNoIHVsdGltYXRlbHkg d2FzIGEgYmFycmllciBpbiB0aGUgd2F5IG9mIEUyRSBjb21tdW5pY2F0aW9ucywgZW5jb3VyYWdp bmcgcGVvcGxlIHRvIGluc3RlYWQgdXNlIG5vcm1hbCBNZXNzZW5nZXIgY29udmVyc2F0aW9ucy4g RW5hYmxpbmcgbXVsdGktZGV2aWNlLCBhbmQgdGhlIGJlaGF2aW91ciBkZXNjcmliZWQgYWJvdmUs IGZpeGVkIHRoaXMgaXNzdWUsIGFuZCB5b3UgY2FuIG5vdyB1c3VhbGx5IGV4cGVjdCBwZW9wbGUg b24gTWVzc2VuZ2VyIHRvIGJlIGFjY2Vzc2libGUgdmlhIFNlY3JldCBDb252ZXJzYXRpb25zLg0K DQogICAgQnV0IHRoYXQgb25seSB3b3JrcyB3aXRoIHNvbWUgZm9ybSBvZiBrZXkgdHJhbnNwYXJl bmN5LCByaWdodD8gT3RoZXJ3aXNlDQogICAgdGhlIGRldmljZSBsaXN0IGNhbiBlYXNpbHkgYmUg bWFuaXB1bGF0ZWQuDQoNClJpZ2h0OiB3aXRob3V0IHRyYW5zcGFyZW5jeSBpdCdzIHBsYXVzaWJs ZSB0aGF0IGEgc2VydmljZSBjYW4gcHJlc2VudCBhIHNwbGl0IHdvcmxkIHZpZXcuIFRoaXMgaXMg d2h5IG91ciB0aHJlYXQgbW9kZWwgY3VycmVudGx5IGZvY3VzZXMgb24ga25vd2luZyB3aGVyZSB5 b3VyIG1lc3NhZ2VzIGFyZSBnb2luZy4gSG93ZXZlciB2aWV3aW5nIHlvdXIgb3duIGRldmljZXMg aW4gdGhpcyB3YXkgYWxsb3dzIHlvdSB0byBhdCBsZWFzdCBzZWUgd2hlcmUgeW91ciBvd24gbWVz c2FnZXMgYXJlIGdvaW5nIChpZiBmb3VsIHBsYXkgaXMgaGFwcGVuaW5nIG9uIHlvdXIgb3duIGFj Y291bnQsIHlvdSBuZWVkIHRvIGtub3cgYWJvdXQgdGhlIGFkZGl0aW9uYWwgZGV2aWNlcykuDQoN Cg0KV2UndmUgZGVmaW5pdGVseSBoYWQgdG8gbWFrZSB0cmFkZS1vZmZzIGluIHRoZSBkZXNpZ24g b2YgdGhpcyBmZWF0dXJlLCBidXQgSSdkIGJlIHN1cnByaXNlZCB0byBoZWFyIGlmIGFueSBhcHAg aGFkbid0IGhhZCB0byBtYWtlIHRyYWRlLW9mZnMuIEhvd2V2ZXIsIEknbSBjZXJ0YWlubHkgbm90 IGFkdm9jYXRpbmcgdGhhdCBNTFMgc2hvdWxkIGJlIGNlbnRyZWQgYXJvdW5kIG91ciBzcGVjaWZp YyB1c2UgY2FzZS4gSSB0aGluayB0aGF0IG91cnMgaXMgb25lIHRoYXQncyB3b3J0aCBzdXBwb3J0 aW5nOyBidXQgdGhhdCB0aGUgdXNlIGNhc2VzIGFjcm9zcyB0aGUgZWNvc3lzdGVtIG9mIHNlY3Vy ZSBtZXNzYWdpbmcgYXBwcyBhcmUgZXF1YWxseSBpbXBvcnRhbnQgdG8gc3VwcG9ydC4NCg0KVGhh bmtzLA0KSm9uDQoNCu+7v09uIDI1LzAzLzIwMTgsIDExOjU1LCAiTUxTIG9uIGJlaGFsZiBvZiBT aW1vbiBGcmllZGJlcmdlciIgPG1scy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzaW1v bi50bHNAYS1vYmVuLm9yZz4gd3JvdGU6DQoNCiAgICAoUmVzZW50IGJlY2F1c2UgSSBoYWQgdGhl IHdyb25nIHNlbmRlciBhZGRyZXNzLikNCiAgICANCiAgICANCiAgICBIaSBKb24hDQogICAgDQog ICAgDQogICAgT24gMjUuMDMuMjAxOCAwMTo0OCwgSm9uIE1pbGxpY2FuIHdyb3RlOg0KICAgID4g SSB0aGluayB0aGlzIGlzIGxpa2VseSBhcHBsaWNhdGlvbi1zcGVjaWZpYywgYnV0IGluIG91ciBj YXNlIHdlIHN1cmZhY2UgYWxsIGRldmljZSBsaXN0IGNoYW5nZXMgd2l0aGluIEUyRSB0aHJlYWRz LCBhbmQgeW91IGNhbiBsb29rIGF0IHRoZSBzcGVjaWZpYyBkZXZpY2UgcHVibGljIGtleXMgaWYg d2lzaC4gSWYgeW91IHNlZSB0aGF0IEkgaGF2ZSBhIG5ldyBkZXZpY2UsIHlvdSBjYW4gdGh1cyAt IGluIHRoZW9yeSAtIGFzayBtZSBvdXQgb2YgYmFuZCB3aGV0aGVyIHRoZSBrZXkgaXMgbGVnaXRp bWF0ZS4gVGhlIHJlbGV2YW50IHBhcnQgb2Ygb3VyIHRocmVhdCBtb2RlbCBoZXJlIGlzICJ5b3Ug c2hvdWxkIGtub3cgd2hhdCBlbmRwb2ludHMgeW91J3JlIHNlbmRpbmcgbWVzc2FnZXMgdG8gYmVm b3JlIHlvdSBzZW5kIHRoZSBtZXNzYWdlIiwgc28gdGhpcyBmdWxmaWxzIHRoYXQgcmVxdWlyZW1l bnQuDQogICAgSSB0aGluayBoYXZpbmcgdGhlIHBhcnRuZXJzIGRlYWwgd2l0aCBuZXcgZGV2aWNl cyBpcyB0aGUgd3JvbmcgYXBwcm9hY2guDQogICAgVGhleSBwcm9iYWJseSBkb24ndCBrbm93IGlm IGEgdXNlciBoYXMgbmV3IGRldmljZXMgc28gYWRkaW5nIHRydXN0IHRvDQogICAgZGV2aWNlcyBz aG91bGQgYmUgaGFuZGxlZCBieSB0aGUgdXNlcnMgd2l0aCB0aGUgZGV2aWNlcy4NCiAgICANCiAg ICANCiAgICA+IEluIG91ciB1c2UgY2FzZSwgdGhpcyBpcyBjb21tb24uIFdoZW5ldmVyIHNvbWVi b2R5IGxvZ3MgaW4gb24gYSBuZXcgZGV2aWNlLCB0aGVyZSdzIGEgc3Ryb25nIGNoYW5jZSB0aGF0 IHRoZXkgZG9uJ3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIHByZXZpb3VzIG9uZSBhdCB0aGUgdGltZSAt IGFuZCB3b24ndCB3YW50IHRvIGJlIGJsb2NrZWQgZnJvbSB1c2luZyBNZXNzZW5nZXIgdW50aWwg dGhleSBjYW4gYXV0aG9yaXNlIHRoZSBuZXcgZGV2aWNlIC0gcGFydGljdWxhcmx5IGlmIGl0J3Mg YSByZXBsYWNlbWVudCBwaG9uZSBmb3IgZXhhbXBsZS4gQXMgRmFjZWJvb2sgTWVzc2VuZ2VyIGl0 c2VsZiBpcyBub3QgYW4gRTJFIGFwcCBpbiB0aGUgZ2VuZXJhbCBjYXNlLCB3ZSB3b3VsZG4ndCB3 YW50IHRvIGFkZCBhZGRpdGlvbmFsIGJhcnJpZXJzIHRoYXQgZGlzY291cmFnZSBwZW9wbGUgZnJv bSB1c2luZyBTZWNyZXQgQ29udmVyc2F0aW9ucy4NCiAgICBJIHRoaW5rIHRoZSBjYXNlcyBvZiBy ZXBsYWNpbmcgZGV2aWNlcyBhbmQgYWRkaW5nIHRoZW0gc2hvdWxkIGJlIHRyZWF0ZWQNCiAgICBk aWZmZXJlbnRseS4gSW4gdGhlIGxhdHRlciBjYXNlIHRydXN0IGhhcyBhbHJlYWR5IGJlZW4gZXN0 YWJsaXNoZWQgYW5kDQogICAgY2FuIGJlIHRyYW5zZmVycmVkLiBJbiB0aGUgZmlyc3QgY2FzZSwg d2hpY2ggaXMgdGhlIGNhc2UgeW91IGFyZQ0KICAgIGNvbmNlcm5lZCB3aXRoLCB0aGVyZSBpcyBu byB0cnVzdCBhbmQgaXQgc2hvdWxkIGJlIGFuIGltcGxlbWVudGF0aW9uDQogICAgZGV0YWlsIHRv IGhpZ2hsaWdodCB0aGlzIHRvIHRoZSB1c2VyIHNvIHRoZSBwcm90b2NvbCBzaG91bGQgbm90IG1h a2UNCiAgICB0aGVtIGVxdWl2YWxlbnQuDQogICAgDQogICAgDQogICAgPiBJIHRoaW5rIEkgYWRk cmVzc2VkIHRoaXMgYWJvdmUsIGJ1dCB3ZSBsZXQgcGVvcGxlIGtub3cgd2hlbiBuZXcgZGV2aWNl cyBhcmUgYWRkZWQgdG8gdGhlaXIgYWNjb3VudC4gVGhvc2Ugd2hvIHdpc2ggdG8gY2FuIGdvIGNo ZWNrIHRoZSBsaXN0IG9mIGRldmljZXMgb24gdGhlaXIgYWNjb3VudCBhdCB0aGlzIHBvaW50Lg0K ICAgIEJ1dCB0aGF0IG9ubHkgd29ya3Mgd2l0aCBzb21lIGZvcm0gb2Yga2V5IHRyYW5zcGFyZW5j eSwgcmlnaHQ/IE90aGVyd2lzZQ0KICAgIHRoZSBkZXZpY2UgbGlzdCBjYW4gZWFzaWx5IGJlIG1h bmlwdWxhdGVkLg0KICAgIA0KICAgIA0KICAgIEJlc3QgUmVnYXJkcywNCiAgICBTaW1vbg0KICAg IA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgTUxTIG1haWxpbmcgbGlzdA0KICAgIE1MU0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fbWxzJmQ9RHdJQ0FnJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPU0wQ1ZF SnlkQlZVWF9idkVxTWE4NFEmbT04SlJoMUtoY1FmSmtvWGs3QV9sVGVHY2Rvd2dFaTFNM0I1Tkli QUhVWmlZJnM9YjloRDVIdUlDaFh0UjhXSnFKdFEyYlVObl9lQzJObEdjNXBuVWg0aHoyQSZlPQ0K ICAgIA0KDQo= From nobody Sun Mar 25 06:28:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FE11250B8 for ; Sun, 25 Mar 2018 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 nWI4JObONN1A for ; Sun, 25 Mar 2018 06:28:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750E51205D3 for ; Sun, 25 Mar 2018 06:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0F0B8BE58; Sun, 25 Mar 2018 14:28:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7gcLmOEuhV7; Sun, 25 Mar 2018 14:28:41 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CABEBBE38; Sun, 25 Mar 2018 14:28:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1521984520; bh=1nveLD4RsFat0jrqgORGfVz1ZINj1a/QBTGN6CxgLSM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rzlUszveoFcyhaMW3NvObzFkryh8wJxF7HpMXChStQL+7/RHjRxMfVuaIdzvgYh+B Ivo9as6eQ8P/Kjkr60cjHqrZireBt/R33kA7QwhiwJZBtMxJci949ZaBNvUYFtm3p7 +AvEvMaylOzcXjJINg6/STnNbzh3oy7oxaLeAOuA= To: Daniel Kahn Gillmor , mls@ietf.org References: <87efk9m7e9.fsf@fifthhorseman.net> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <96e05d98-850c-68ce-403f-7320135761f8@cs.tcd.ie> Date: Sun, 25 Mar 2018 14:28:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <87efk9m7e9.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D25udf2aAGFz6jZxoCCopatKfkfHSqMQr" Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 13:28:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D25udf2aAGFz6jZxoCCopatKfkfHSqMQr Content-Type: multipart/mixed; boundary="QCvQYNQmWpJbMe6gOyxLkzS2qi3jaXVyx"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , mls@ietf.org Message-ID: <96e05d98-850c-68ce-403f-7320135761f8@cs.tcd.ie> Subject: Re: [MLS] multiple devices per user? References: <87efk9m7e9.fsf@fifthhorseman.net> In-Reply-To: <87efk9m7e9.fsf@fifthhorseman.net> --QCvQYNQmWpJbMe6gOyxLkzS2qi3jaXVyx Content-Type: multipart/mixed; boundary="------------2A73182CCF1CC9AD30730314" Content-Language: en-GB This is a multi-part message in MIME format. --------------2A73182CCF1CC9AD30730314 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/03/18 22:32, Daniel Kahn Gillmor wrote: >=20 > Wouldn't it be safer and simpler to assume a design that insists on > single-key-per-user, and hide multi-device private-key-synchronization > from the other participants in the group chat? Speaking as a user and teeny-weeny service operator (most recently of the riot/matrix variety), but not as an implementer:- - I've no problem with device specifics being visible to the small groups of which I'm a member or that I support. - I would prefer that device specific details not be visible in larger settings, e.g. were I a member of a group with ~100 members or more say, or if using some federation scheme, where I won't necessarily know group sizes or memberships. - I understand that it might be simpler to treat each device independently within MLS, but would be happier if the WG spent a bit of time considering whether it is possible to do better and provide a way for applications to hide device specifics if that makes sense to the application. Cheers, S. --------------2A73182CCF1CC9AD30730314 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------2A73182CCF1CC9AD30730314-- --QCvQYNQmWpJbMe6gOyxLkzS2qi3jaXVyx-- --D25udf2aAGFz6jZxoCCopatKfkfHSqMQr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJat6QIAAoJEFqy+vF7Fyvq4bkQAMj1Nk97Z8Nw3catPl1KcC84 wRyM09BYk58OBon5jplR3TSdVM5rc9aKVUKGr/sD2dTV6UnvS6fQ4t/CM7lLqdOt sUljiiPSTerEs2BL9IZ+wpC7DVKpnBTQI467auuD691KkXSOjOr6gu9JheJ96AD5 iP0SBqa0U7FwGqPCmgLDTqu0aHAB59IKhAkq3u1Zkvn251m7RszpQ2ZiTOw1dOOT 9W3AScjB3vVeDwmz/7jEVQ8NUBDCgmFmsakvcbTvCOHbreriiqxRqw6yKYr+K9hk VYB2tEjemubyYsLlxRBw+ZS2TmkuamW0VEbXOrpTax87rpT+LqSKWC/6ObCbjirv dcf6mLLqeluasgmwdvAnnOnTMb2KH25Y8JQ5mcGrRWubM2sXphiW8mz1Xgx8RA3V w9vS/pm0KxH92XGDaU6KvkoQdzgTsFq20BSR8rR17ozD6NQdZjXdVxQ2Rl22fnTL CvAxLbMnT89mgaaPHp/cD4LFNN36OyGjPls927v+tJwZzSjjbJs+WOoftEstEL9M 07mTBzZUozhE7/boVPDOHeUkIYP9ql3wJQd4Ih9kiXEfeA4zGQR4s9Xuh3rk/ETP kFf0YXPM0uK+GyMszbJ28piNg5ubPdj1ymmg5I8Q4SLUN86OqMTTnGvMySKDexpY 6gOJh8+uDUMcq0DVb7bG =TSKA -----END PGP SIGNATURE----- --D25udf2aAGFz6jZxoCCopatKfkfHSqMQr-- From nobody Sun Mar 25 06:38:04 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992F51250B8 for ; Sun, 25 Mar 2018 06:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCiY4QIAO1h9 for ; Sun, 25 Mar 2018 06:38:01 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019851205D3 for ; Sun, 25 Mar 2018 06:38:01 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f05qN-0001d0-5Y for mls@ietf.org; Sun, 25 Mar 2018 15:37:59 +0200 To: mls@ietf.org References: <77e637fe-635f-b696-879d-e99add067b03@a-oben.org> From: Simon Friedberger Message-ID: Date: Sun, 25 Mar 2018 15:37:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [MLS] Fwd: Re: multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 13:38:03 -0000 On 25.03.2018 14:23, Eric Rescorla wrote: > > Well, I wasn't suggesting we adopt the Firefox protocol, merely that > the UX > requirements of a scheme which required key transfer were not good. > Maybe you should. I quite like the idea! :) From nobody Sun Mar 25 06:40:37 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7AF1250B8 for ; Sun, 25 Mar 2018 06:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1HUU_CwnXAQ for ; Sun, 25 Mar 2018 06:40:33 -0700 (PDT) Received: from a-oben.org (squint.a-oben.org [144.76.111.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887A21205D3 for ; Sun, 25 Mar 2018 06:40:33 -0700 (PDT) Received: from [81.164.186.174] (helo=[192.168.0.234]) by a-oben.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1f05st-00041Q-P2 for mls@ietf.org; Sun, 25 Mar 2018 15:40:32 +0200 To: mls@ietf.org References: <5c6e6bb1-6efb-b5f4-e52e-93997c58caa8@friedberger.de> <795f77d0-d486-8134-9e15-da0d0107c018@a-oben.org> <0273A6A6-A491-4DC2-9B07-8B048EE4B537@fb.com> From: Simon Friedberger Message-ID: <1460092f-0b46-3ae7-d2bc-174f225be6c6@a-oben.org> Date: Sun, 25 Mar 2018 15:40:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0273A6A6-A491-4DC2-9B07-8B048EE4B537@fb.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [MLS] Fwd: Re: multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 13:40:35 -0000 Hi Jon! On 25.03.2018 15:21, Jon Millican wrote: > As I say, this is a specific use case in which we require devices to wo= rk immediately on log in. Yes, I totally agree that this should work. I would like to see a solution with some kind of transition state where you can talk to a device encrypted but it is clear that no authentication has been performed yet. This can then be remedied by either comparing fingerprints or scanning qr codes or authenticating from one of your other devices. > I think the cases of replacing devices and adding them should be tr= eated > differently. In the latter case trust has already been established = and > can be transferred. In the first case, which is the case you are > concerned with, there is no trust and it should be an implementatio= n > detail to highlight this to the user so the protocol should not mak= e > them equivalent. > > This cuts to the reason why explicitly enrolling devices from trusted d= evices would be difficult for us. It's a common situation in which the or= iginal device is no longer available for whatever reason (lost, stolen, b= roken, sold, etc), so new devices that people log in to simply wouldn't b= e able to use Secret Conversations without choosing to explicitly enable = the new device for it. Not only does this make things harder for people w= ho explicitly plan to send an E2E message, but it means that people who d= on't know about the E2E mode will simply become inaccessible over time as= they upgrade devices; and those people who do explicitly want to use Sec= ret Conversations won't be able to reach their friends who are unaware of= /uninterested in the feature. I'm not speaking in hypotheticals here; the= original version of Secret Conversations worked in exactly this way: it = was single-device per user, so if you replaced your phone, you would have= to explicitly enable Secret Conversations on the new device, otherwise t= he enrolled device for your account would remain as the one that was enab= led when we originally rolled out the feature. Over time, it was easily o= bservable that people would become inaccessible via the feature, which ul= timately was a barrier in the way of E2E communications, encouraging peop= le to instead use normal Messenger conversations. Enabling multi-device, = and the behaviour described above, fixed this issue, and you can now usua= lly expect people on Messenger to be accessible via Secret Conversations.= Trying to pick this apart... I agree with you that device loss has to be handled somehow and it would be nice if it could be handled smoothly and in a way that can be used if the device is just not available right now. I don't quite understand the issue of people becoming unavailable. If they have been so oblivious to encryption in the first place they probably never performed any authentication and giving them a new key doesn't actually make a difference. It seems like this problem is very UI/UX related. - Simon From nobody Sun Mar 25 12:33:50 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB077124234 for ; Sun, 25 Mar 2018 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symbolic.software 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 HLIjKVl8s6p2 for ; Sun, 25 Mar 2018 12:33:46 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99941200FC for ; Sun, 25 Mar 2018 12:33:45 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id t7so11690059wmh.5 for ; Sun, 25 Mar 2018 12:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uABYMFV0XXM85/mHqf64ZAnryrpE1V4mR5+66iFv69s=; b=ZAw116XgjdOGX24j1AhMSvoqPoFtCPzrd04JlDCYiVcJLAE5FnCuhDEkUT459FiH7C /wxOCr5vnzKUU9j5nrxM/vTDUVu+ZwkWSjBKxOkVZFCZsHkZDNUVWKbGx+3T1jeYxZ2g SIKOmKG0btQQ1Jf8QBF3VOOYLKBbNqjp7txG0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uABYMFV0XXM85/mHqf64ZAnryrpE1V4mR5+66iFv69s=; b=idi9aV8OfcqJcCcqZh5MdA+BxcFnVuEwRkIiAol4irBb2PaHh1s6ITLXgOYenTQHNE KmhHeLy3hN5PglecujWNcpbqLeGuMCYYn+BK8kxWCExbR01SqxM3/4ZikC0kikw4pdqU 5YVKXWCZBMRprwsYkeOdM/BowpHKOtTz0MCVFRE4adUOUjhHrO1/LxIsGOldvEW9Uc00 qQWITR2L4wWI2+X0Mvk7IVDsOxjUkmiBaTgt7LQtl5/tSLNOPOjV7BsQxmjAdzaHYCAh VrydufEeRmOa0fsLdjTYy88GnENqVmi2ueQrU9IatYRDtu+vY+22y0460oi52C6UyZhz ECDg== X-Gm-Message-State: AElRT7HVVjg08oc/I0/Xbygn+kGnNveNin7KyY+/YCwKyZuyuD9/z7eu KCWN5UPYUE7UlorHxdEm1TXXOw== X-Google-Smtp-Source: AG47ELvJp/Er7PzCPUnuSBnHTmpGJr3mA/CEzeQRFxCoOHfKC8tx5OypOu+7yQ/3Pzjn7y1CoSHLaA== X-Received: by 10.28.128.206 with SMTP id b197mr12902806wmd.48.1522006424043; Sun, 25 Mar 2018 12:33:44 -0700 (PDT) Received: from nadims-macbook.home (2a01cb0003e8c80059aa610b69c68f0b.ipv6.abo.wanadoo.fr. [2a01:cb00:3e8:c800:59aa:610b:69c6:8f0b]) by smtp.gmail.com with ESMTPSA id p68sm15224915wmg.7.2018.03.25.12.33.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Mar 2018 12:33:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Nadim Kobeissi In-Reply-To: Date: Sun, 25 Mar 2018 21:33:42 +0200 Cc: Raphael Robert , mls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> To: Suhas Nandakumar X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 19:33:49 -0000 I do not believe the name should be changed: 1. MLS is a protocol that is equally suited for pairwise messaging as it = is for group messaging 2. The MLS name is elegant and mirrors TLS. I would recommend not spending a lot of time on this. Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software Sent from office > On Mar 24, 2018, at 4:31 PM, Suhas Nandakumar = wrote: >=20 > 'mls' seems to be a fine name as it indicates e2e security for = messaging layer of the stack. Group vs 1:1 is a realization of an = application context on top of such a abstraction layer is what i feel. >=20 > ./S >=20 >=20 >=20 > On Sat, Mar 24, 2018 at 8:25 AM, Raphael Robert = wrote: > We looked at a number of alternatives to MLS and in the end none of = them seemed to be substantially better than =E2=80=9CMessaging Layer = Security=E2=80=9D, but that doesn=E2=80=99t mean the name cannot be = changed.. >=20 > In my opinion =E2=80=9Cmessaging=E2=80=9D implies groups in 2018 and = it=E2=80=99s not a special case of messaging anymore. It's the norm for = non-E2EE products, and a number of E2EE messengers support it as well = already today: WhatsApp, Signal, Wire, etc. In the context of MLS, = =E2=80=9Cgroups" are also interchangeable with =E2=80=9Cmulti-device=E2=80= =9D, which is also becoming the norm. >=20 > The 1:1 pairwise mode is still important technologically, but = application-wise it will most likely be perceived as a special case of = (group) messaging.. >=20 > Also just my 2c. >=20 > Raphael >=20 >> On 24 Mar 2018, at 15:05, Katriel Cohn-Gordon = wrote: >>=20 >> +1 >>=20 >> I have no strong feelings regarding the name, but I do think we are = working on groups because you need them for general messaging. >>=20 >> Katriel >>=20 >>=20 >> On Sat, 24 Mar 2018, at 1:43 PM, Jon Millican wrote: >>> Thanks for raising this point. I'm also no good at naming, but agree = that there's potential scope to name more clearly. A couple of points in = response to the specific issues you raised though: >>>=20 >>> While most of the discussion has focused on groups, my feeling is = that this is because group is a more challenging superset of the = pairwise case; and we should still care about pairwise messaging. In the = pairwise case I think the main differentiator compared with TLS is the = requirement for asynchronicity; so if we're clearly carving up the = territory it might make sense to highlight this. >>>=20 >>> Just my 2c though. I have no objection at all to changing the name, = and certainly agree that group support is a crucial aspect that could be = worth highlighting. >>>=20 >>>=20 >>> Jon >>>=20 >>> On 24 Mar 2018, at 13:15, Shivan wrote: >>>=20 >>>> +1 the name seems to be inspired by TLS but the drafts concern = themselves explicitly with group messaging, not messaging as a whole. =20= >>>>=20 >>>> On Sat, Mar 24, 2018, 11:28 AM Daniel Kahn Gillmor = wrote: >>>> Thanks for all the work that has gone into the proposed MLS = architecture >>>> and protocol drafts already. >>>>=20 >>>> As we move toward working group formation, i'm a little bit = concerned >>>> that the ostensible name of the project ("message layer security") >>>> doesn't adequately describe the most salient features. >>>>=20 >>>> We spent most of the time at the BoF in IETF 101 London talking = about >>>> the design of the group key agreement scheme and the strong >>>> cryptographic properties we want it to provide -- and i suspect = that >>>> most of the work in any formed WG will center around that problem. >>>>=20 >>>> So it seems odd to me that the word "group" doesn't appear in the = name >>>> "MLS". >>>>=20 >>>> I'm no good at acronyms, but i'll just throw out two alternatives: >>>>=20 >>>> MSG: Messaging Security for Groups >>>>=20 >>>> MESSAGE: Message Encryption and Security Standard for = Asynchronous Group Environments >>>>=20 >>>> I hope since the WG isn't yet formed, it's not too late to consider = a >>>> change to the name. We ought to be up front about the = group-specific >>>> context that we're talking about here, as we already have a = security >>>> layer that works for messages passing between two endpoints >>>> synchronously (TLS) and it'd be nice to clearly carve up the = territory. >>>>=20 >>>> --dkg >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mls >>>> _______________________________________________ >>>> MLS mailing list >>>> MLS@ietf.org >>>> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf..org_mailm= an_listinfo_mls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DM0CVEJydBVUX_bvE= qMa84Q&m=3Dq5KP1AJUu-4ir-39yrQWELe1gULZ7UQbevfDBrgr0ss&s=3DjlPCTk9fCDAvKt6= l2DuFKYLJoRLEL_KXV7lPHhtlA3M&e=3D >>> _______________________________________________ >>> MLS mailing list >>> MLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mls >>=20 >> _______________________________________________ >> MLS mailing list >> MLS@ietf.org >> https://www.ietf.org/mailman/listinfo/mls >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls >=20 >=20 > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls From nobody Mon Mar 26 01:24:15 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E581205F0 for ; Mon, 26 Mar 2018 01:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 304RgAFYPIwT for ; Mon, 26 Mar 2018 01:24:13 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 27DF51204DA for ; Mon, 26 Mar 2018 01:24:13 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id t132-v6so26837038lfe.2 for ; Mon, 26 Mar 2018 01:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hejmSc4pQ/kjDXiIwc/9HmP+OfWCR7bEwVeGeurXfH4=; b=iKcCItlbTqw47FQzDtZPr1c3eXaE/7ZPVSYbcb/v2qsDtft2bPM3SEUXHbRt0J3ToD iZS/uUqG5FRzOqcp2ynTGeeX9CdVNUcynmA5uroPsHCJ5gEQLJnnMA1ygI0GZFyyCNXP 6j7TCD5b/iMcRoHyzBEAOVng0WK3m/mrHtBas= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hejmSc4pQ/kjDXiIwc/9HmP+OfWCR7bEwVeGeurXfH4=; b=ZvI6MaMlHXwu20/jySyfX1Pjq1VyGcl6LYMpOTf/JaLbjJGN1x4GHKJOVdGfEm4lzC mqtHUc0NWp2dZzA8iJjEwkv24aU1/nw3GX1O6nIcWeAozRNQhaedza+hp9cL4GPTrHuR pRVrPxK5SyHvZZ/GzRg5QDyH9LuPfDGWxodIqe4GvVKmaecB7ksfbLAFv2AkdxXi4BLl FYl9MRs7kQChUIqLOqWQEJ56RtThGtboUh9WsLLtt29HWArevJCS2vywxDgMBksHsa3q ngWZvc3UXNnVnSrYYEurjVTKYEvYcO57jn9Uva79x2zfx7hf83MRUfMRuN9PokKBJrXA 9yQg== X-Gm-Message-State: AElRT7HHjXjHioDamDdcvceqgGXEQdwdrkWImV7RBO7PmgNWxxR3f2sV wRsxeLEw+Q0iQoyvWKevGIKwHalrmee47H+MWXIdpD63 X-Google-Smtp-Source: AG47ELtcyGK5UtfnTmwKWU9Uv5tgiECMVfXpWQVAu0ul3AGnXvuCkOA3tUYVuOsM+6YGmms4dijqTwVBjB21Cch/XQo= X-Received: by 2002:a19:9904:: with SMTP id b4-v6mr25142150lfe.51.1522052651317; Mon, 26 Mar 2018 01:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.71.226 with HTTP; Mon, 26 Mar 2018 01:24:10 -0700 (PDT) In-Reply-To: <87r2o9n277.fsf@fifthhorseman.net> References: <87r2o9n277.fsf@fifthhorseman.net> From: Dave Cridland Date: Mon, 26 Mar 2018 09:24:10 +0100 Message-ID: To: Daniel Kahn Gillmor Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000009c964705684c7ff8" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 08:24:15 -0000 --0000000000009c964705684c7ff8 Content-Type: text/plain; charset="UTF-8" I believe we should make it out of wood. It's a renewable resource and, if well-treated, will be more than adequate for keeping the effects of weather off the cycles stored inside. On 24 March 2018 at 11:27, Daniel Kahn Gillmor wrote: > Thanks for all the work that has gone into the proposed MLS architecture > and protocol drafts already. > > As we move toward working group formation, i'm a little bit concerned > that the ostensible name of the project ("message layer security") > doesn't adequately describe the most salient features. > > We spent most of the time at the BoF in IETF 101 London talking about > the design of the group key agreement scheme and the strong > cryptographic properties we want it to provide -- and i suspect that > most of the work in any formed WG will center around that problem. > > So it seems odd to me that the word "group" doesn't appear in the name > "MLS". > > I'm no good at acronyms, but i'll just throw out two alternatives: > > MSG: Messaging Security for Groups > > MESSAGE: Message Encryption and Security Standard for Asynchronous Group > Environments > > I hope since the WG isn't yet formed, it's not too late to consider a > change to the name. We ought to be up front about the group-specific > context that we're talking about here, as we already have a security > layer that works for messages passing between two endpoints > synchronously (TLS) and it'd be nice to clearly carve up the territory. > > --dkg > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --0000000000009c964705684c7ff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe we should make it out of wood. It's a renewa= ble resource and, if well-treated, will be more than adequate for keeping t= he effects of weather off the cycles stored inside.

On 24 March 2018 at 11:27, Daniel K= ahn Gillmor <dkg@fifthhorseman.net> wrote:
Thanks for all the work that has gone into the propose= d MLS architecture
and protocol drafts already.

As we move toward working group formation, i'm a little bit concerned that the ostensible name of the project ("message layer security"= )
doesn't adequately describe the most salient features.

We spent most of the time at the BoF in IETF 101 London talking about
the design of the group key agreement scheme and the strong
cryptographic properties we want it to provide -- and i suspect that
most of the work in any formed WG will center around that problem.

So it seems odd to me that the word "group" doesn't appear in= the name
"MLS".

I'm no good at acronyms, but i'll just throw out two alternatives:<= br>
=C2=A0 MSG: Messaging Security for Groups

=C2=A0 MESSAGE: Message Encryption and Security Standard for Asynchronous G= roup Environments

I hope since the WG isn't yet formed, it's not too late to consider= a
change to the name.=C2=A0 We ought to be up front about the group-specific<= br> context that we're talking about here, as we already have a security layer that works for messages passing between two endpoints
synchronously (TLS) and it'd be nice to clearly carve up the territory.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg

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


--0000000000009c964705684c7ff8-- From nobody Mon Mar 26 02:16:35 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5D51243F6 for ; Mon, 26 Mar 2018 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5-KHdWf9AOv for ; Mon, 26 Mar 2018 02:16:32 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 6A9E51241FC for ; Mon, 26 Mar 2018 02:16:32 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id p67-v6so9835812itc.2 for ; Mon, 26 Mar 2018 02:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6SAMVEi+gMJJNJ78lK3d7mx/E8/cuCpG+WRnVXdMtyA=; b=gIO7pq8Gg3y5GpoZYtWRYyOQ2cpxVfSy6T80UgwJ5rET4SudCwY1CeaS3u6EIcQQ5L kDaZxAxdBEE50MT8YNj/bGBrWBbDGV/AuCJfFv4qYBpYIvLD9ge6r1zw7mbjlzO+MKZ0 Fx2xe2YGsLc+88Mj3EBqvMTTPJpDSPBK1pre/8VSEgY3bNLOaRu5tKFO2fsd19dPhsSW sWziErL58nFP4Xys0q1sOHuMvnn14NicW/D5oVGPtXNXzhT6Mxd3xMWg2P3R70oBYhDM 4gvGaVV1k6BtoVLuXiauxM6HyM1b7YW7dKncifbKWdkvX0mHO05iI0HxDaqTaNq+fLia Klnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6SAMVEi+gMJJNJ78lK3d7mx/E8/cuCpG+WRnVXdMtyA=; b=gVCuL73haZaIFp1hQlWSEJxvmU4oxTMha42IUh3cr6SQrJP7GksswQZLPdIcaN7KfF QgBnCNL612uhiETI9WGqxtxRGsXmfAanBYUYtcICRZ4RvUHWn2lQuE+aoyxrFN0PV7LO uzQpx5nzbnIwkkKLQKdE6OB6/dw3jbTdF0ZVXwicJ+tW/4nU9TzYS4HHYgzMlw3Iyv5d 9+zlGXxyD/C9/JizKkZvzn2og0p1ntjkEmrEx5obI3HmJLc5L7ivShpb6EqXz6yOSWXx 135xaMmGaflC46tSKbM7D43CA5Py/jeVoUz2Buwst5GXd9H+rrROzaYmJpUCGL28ICfR IxtA== X-Gm-Message-State: AElRT7GN40dyZAE+26WjnqB367D84MYqUN44iondFEcviQMJZGtKqLk6 H4QTU/Amrm0rRywrFtzuEPw8HLzn X-Google-Smtp-Source: AIpwx49R0ZTaH0GoxBngUPTXmIo68BLliFHw7NMQVX43kfedr9Vnp15GFQ/2w7K91VWNCcsY7QoH4Q== X-Received: by 2002:a24:30c:: with SMTP id e12-v6mr3837886ite.50.1522055791809; Mon, 26 Mar 2018 02:16:31 -0700 (PDT) Received: from [100.64.72.2] ([173.245.215.240]) by smtp.gmail.com with ESMTPSA id k4-v6sm9634694ith.4.2018.03.26.02.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 02:16:30 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A10A8F7A-23E4-4486-A6F7-C7FB8D14718D Mime-Version: 1.0 (1.0) From: Rich Persaud X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Mon, 26 Mar 2018 05:16:30 -0400 Cc: Daniel Kahn Gillmor , mls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <7F2CA103-751F-4386-BC47-34FD5E337FC6@gmail.com> References: <87efk9m7e9.fsf@fifthhorseman.net> To: Eric Rescorla Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 09:16:34 -0000 --Apple-Mail-A10A8F7A-23E4-4486-A6F7-C7FB8D14718D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Mar 24, 2018, at 18:42, Eric Rescorla wrote: >> On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor wrote: >>=20 >> Furthermore, it's not clear what a group conversation participant can >> *do*, security-wise, in the event of recieving such a message from >> another participant -- is this actually a new phone, or is it a wiretap >> injection? should i ask the user about it? should i take action? what >> ction? In Wire, if Alice has marked each of Bob's device fingerprints as "verified"= , then the addition of a new device by Bob results in an immediate message t= o Alice. The recommended action is to verify the new fingerprint out of ban= d, then Alice can mark Bob's new device as "verified".=20 > Generally, I wouldn't expect them to take any action at all. It's a user's= > responsibility to ensure that the right number of devices are registered > to their account, just as its common for the number of Web browsers > one has attached to ones Gmail account. Here is a scenario on iOS: (1) User is logged into Facebook via Chrome. User is not logged into Facebo= ok in Safari, to avoid Facebook tracking on non-Facebook websites visited in= Safari. (2) User receives FB email notification in Apple email. If user clicks on a= link in the email, it opens in Safari and Facebook *automatically logs the u= ser in without a password*. (3) User then receives FB email notification that they have added a new devi= ce. (4) User must now manually log out of Facebook, then click on a tiny close b= utton on account icon to delete the cookie associated with that user, to avo= id Facebook tracking on non-Facebook websites. That removes (?) the browser= as a known device. Each of the individual UX decisions above could make sense in some contexts,= but when combined on iOS where the user cannot choose the browser in which e= mail links are opened, it leads to an undesirable UX where the user must inv= est repeated effort to ensure that the right number of devices are registere= d to their account. Rich= --Apple-Mail-A10A8F7A-23E4-4486-A6F7-C7FB8D14718D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mar 24, 2018, at 18:42, E= ric Rescorla <ekr@rtfm.com> wrote:=
On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kah= n Gillmor <dkg@fifthhorseman.net> wrote:

Furthermore, it's not clear what a group conversation participant can
*do*, security-wise, in the event of recieving such a message from
another participant -- is this actually a new phone, or is it a wiretap
injection?  should i ask the user about it?  should i take action?=   what
ction?

<= div>In Wire, if Alice has marked each of Bob's device fingerprints as "verif= ied", then the addition of a new device by Bob results in an immediate messa= ge to Alice.  The recommended action is to verify the new fingerprint o= ut of band, then Alice can mark Bob's new device as "verified". <= div>

Generally, I wou= ldn't expect them to take any action at all. It's a user's
respons= ibility to ensure that the right number of devices are registered
= to their account, just as its common for the number of Web browsers
one has attached to ones Gmail account.

Here is a scenario on iOS:

(1) Use= r is logged into Facebook via Chrome.  User is not logged into Facebook= in Safari, to avoid Facebook tracking on non-Facebook websites visited in S= afari.

(2) User receives FB email notification in A= pple email.  If user clicks on a link in the email, it opens in Safari a= nd Facebook *automatically logs the user in without a password*.
<= br>
(3) User then receives FB email notification that they have ad= ded a new device.

(4) User must now manually log ou= t of Facebook, then click on a tiny close button on account icon to delete t= he cookie associated with that user, to avoid Facebook tracking on non-Faceb= ook websites.  That removes (?) the browser as a known device.

Each of the individual UX decisions above could make sense i= n some contexts, but when combined on iOS where the user cannot choose the b= rowser in which email links are opened, it leads to an undesirable UX where t= he user must invest repeated effort to ensure that the right number of devic= es are registered to their account.

Rich
= --Apple-Mail-A10A8F7A-23E4-4486-A6F7-C7FB8D14718D-- From nobody Mon Mar 26 02:23:56 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3601112422F for ; Mon, 26 Mar 2018 02:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-NkccRhh3U3 for ; Mon, 26 Mar 2018 02:23:53 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3211241FC for ; Mon, 26 Mar 2018 02:23:53 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id z143-v6so11785311itc.0 for ; Mon, 26 Mar 2018 02:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/BWOMm2Vaf23hczIg61EaGWk6EJnE/NF/dbIKsyWuOU=; b=uuVibaLrPgYdXF8Uf1losKBGxJPZduCeCMpu4b2VAa3o3UW5psEonw95/w+EeKUWoA M0UFnNVoKrnYKzV5UXo5P35tQn2LTSQ7RDO2cXURCFvPCGWF0Qf9okiv6lwtDr9P2135 k3pU/C8fInGTtjTgA4dGKXzzA7LpXaGgtO4k6vRhXcIrBHAohpppjJCeqqZ35zCHgaj0 czqOxSJMy2iNSStqgRQ/HAmHsGaQF4Fz/vZws25HiBLuRXo096dd3KEogCoKCDP8PBUU fTvzPiOqSrav3ieUkU4q+iZokuh9jeKffS0BPdibOX9llHORI2JqE0Mx5LH0nDd4LzVH VLYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/BWOMm2Vaf23hczIg61EaGWk6EJnE/NF/dbIKsyWuOU=; b=Kr1Qrl/xyaHhtuV16SDTwbSA3PMsCAFWu2XyEwVRsxQVv1Th2dAfCbp6E/xulBasiF H5b9KguEdejxc/5aaxgp5j7eiDmzPh7vSKGcSAHxs87drGYkJmGoZSTgQi65E1ZzC4D2 Us1PiRMzHRBNYaqwqWPMS0AYTwrkjGYWqqQWbDiRc/PZudmeDSrAlqCwx10eWR8Yp1hs g5RU4giLPWaofmM1ZTyzhHuwrBwk28kDdhaOuU8WXPonT9FcPXYL4qT+poR9mYIfV18/ sOPTBMfN0WazkMt33tR+q0xgKC/DkiOErAp07jungoTd5dISVcer/5CZM5wEvxU1wDdh 2PFw== X-Gm-Message-State: AElRT7EmPO18j+I+fJI4uf6sffI3N+oyqqixx/E7/keyHzR76vP3zJnw Mestn0dbXvGRhFZQqQu7FcJLuQhP X-Google-Smtp-Source: AIpwx49WgH2KjGuSakBuXMg5lJQR/Mck8oaqnT7bfA9Iq49FVI5Uykc/uvamnMeytjls+qnD87F71g== X-Received: by 2002:a24:30c:: with SMTP id e12-v6mr3854142ite.50.1522056232945; Mon, 26 Mar 2018 02:23:52 -0700 (PDT) Received: from [100.64.72.2] ([173.245.215.240]) by smtp.gmail.com with ESMTPSA id s142-v6sm4037071itb.4.2018.03.26.02.23.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 02:23:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-BD570259-DE66-4511-96D2-85875C460153 Mime-Version: 1.0 (1.0) From: Rich Persaud X-Mailer: iPad Mail (15D100) In-Reply-To: Date: Mon, 26 Mar 2018 05:23:51 -0400 Cc: mls@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <29A3652D-76EB-4830-8337-819EE19D597C@gmail.com> References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> To: Raphael Robert Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 09:23:55 -0000 --Apple-Mail-BD570259-DE66-4511-96D2-85875C460153 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mar 24, 2018, at 11:25, Raphael Robert wrote: >=20 > We looked at a number of alternatives to MLS and in the end none of them s= eemed to be substantially better than =E2=80=9CMessaging Layer Security=E2=80= =9D, but that doesn=E2=80=99t mean the name cannot be changed. There is potential for collision with the MLS acronym that has been used for= years (decades?), especially when combined with search terms like "security= " or "cryptography": https://en.wikipedia.org/wiki/Multilevel_security Rich= --Apple-Mail-BD570259-DE66-4511-96D2-85875C460153 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mar 24, 2018, at 11:25, R= aphael Robert <raphael@wire.com&g= t; wrote:

We looked at a num= ber of alternatives to MLS and in the end none of them seemed to be substant= ially better than =E2=80=9CMessaging Layer Security=E2=80=9D, but that doesn= =E2=80=99t mean the name cannot be changed.

There= is potential for collision with the MLS acronym that has been used for year= s (decades?), especially when combined with search terms like "security" or "= cryptography":  https://en.wikipedia.org/wiki/Multilevel_security
Rich
= --Apple-Mail-BD570259-DE66-4511-96D2-85875C460153-- From nobody Mon Mar 26 14:45:58 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C800126CF6 for ; Mon, 26 Mar 2018 14:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 9w1yhfsW7QS7 for ; Mon, 26 Mar 2018 14:45:54 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 EF1DD126CB6 for ; Mon, 26 Mar 2018 14:45:53 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r82so18185184wme.0 for ; Mon, 26 Mar 2018 14:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SvwTezzgf/gmTQNGSS8iEoUPuDxIGbIBThqmgarIrgU=; b=fG9Nxj1MAoAnrhFwbPb2KLr+T9NVOnnY+lLrACqUrkWT+u2PJRd/5aEe2+fwCidXzU 8x2WNgAMFb2J0CvsTANNWTJ8Rl81djjg1syIMBWCj8MvU+j4CT1kMe6bEmukoBXg58+/ e4ALCCMto3JeolpZJg9fAnUg68FB1lxnz4/TqBVv+Q3++3CHvraoEPq5SupSM3tM8GGe 5ZH54z7U/CEC5TNBdbIXzngL0lNK+sIRgw3ZvV/XLFNFoxyqy2yTQoAwMlVyAygNzYwe hZw0bJcraJyYtGk2DwKxkR/cYWt8I/rpJomEZjvdwCZ9x3JNWcqf5I+qlsNkiJlHvX+v 0Ybg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SvwTezzgf/gmTQNGSS8iEoUPuDxIGbIBThqmgarIrgU=; b=GySfr1a6lJcBxrFvJ4NoRQoXpoQV3n5xHcPDVuRkguj09Ey0czUIPWo1j7HXo4SPCO MdktWt3rNIGKehHJJiB1/ZV0qjD0/o4iMtIcz88lbqbAyW+583PhX38+ihyBL65ZjS5E 06enRpDS8HzbbyYWQAP5zkMINTR8D+g53qLETA2p0uTSBBZYgi/FE502vdf9cMEJdC/o LKeDqMyCRXkotTcJOE4LlvsyLLMDxKil+H1pPbEodfDZePWpiJlIhvVDSjbFrmP2N3Ir uePeEJxlLCQT7yc9jOkOvFD0hHzYkDzNRVOswG9XKcMzg1UNKpzhMCqeXWju3pT9Lnmy pqlA== X-Gm-Message-State: AElRT7Gph8Y+gGlFvibuZb/+hJtIer41J6XNVOqvQDO7Bv41fMNKlOZM GpvHaRtltP7cX/vNifSTqKB0L7Y2PQBS+ox/UVXYuA== X-Google-Smtp-Source: AG47ELu+73GC+oGIYQKKDYG1Ex+VawcQPAJgLbUsSQetkNV2xplVIrBu9D/SJR7d4CcXtLF1fgFrqMcj5DAY63GJmcY= X-Received: by 10.28.6.149 with SMTP id 143mr17866970wmg.61.1522100752133; Mon, 26 Mar 2018 14:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Mon, 26 Mar 2018 14:45:51 -0700 (PDT) In-Reply-To: <7F2CA103-751F-4386-BC47-34FD5E337FC6@gmail.com> References: <87efk9m7e9.fsf@fifthhorseman.net> <7F2CA103-751F-4386-BC47-34FD5E337FC6@gmail.com> From: Richard Barnes Date: Mon, 26 Mar 2018 22:45:51 +0100 Message-ID: To: Rich Persaud Cc: Eric Rescorla , mls@ietf.org, Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary="001a11442348a4c531056857b260" Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 21:45:56 -0000 --001a11442348a4c531056857b260 Content-Type: text/plain; charset="UTF-8" Hey all, Sorry, I was in meetings over the weekend and missed the fun :) Let me try to sum up. tl;dr: It's an application decision. The protocol should be oriented around per-device keys, but we should also document the privacy concerns and some approaches to mitigating them. I agree with DKG that we should not hard-code a one-key-per-device assumption into the protocol. But at the same time, I don't want this group to have to assume the complexity of a protocol to sync keys across devices in addition to what it's already got. And has been pointed out, there are some valid reason to want individual device keys to be exposed in the protocol, e.g., key comparison and device revocation. Fortunately, we don't have to make a choice here. Because the protocol doesn't know whether a leaf key is an actual leaf or the root of a subtree, there's a clean interface point where applications can make a decision. You could even imagine different clients in one group making different decisions. So I would suggest we do the following: - No change to the protocol document - In the architecture document: - Lay out the privacy risk that can arise from using per-device keys - Present the two approaches discussed in this thread for how to do key sync (explicit sync and sub-trees) That way, the WG's document set will provide guidance to implementors about the risks and how to mitigate, without diving into the complexity of a full protocol. --Richard On Mon, Mar 26, 2018 at 10:16 AM, Rich Persaud wrote: > On Mar 24, 2018, at 18:42, Eric Rescorla wrote: > > On Sat, Mar 24, 2018 at 10:32 PM, Daniel Kahn Gillmor < > dkg@fifthhorseman.net> wrote: > >> >> Furthermore, it's not clear what a group conversation participant can >> *do*, security-wise, in the event of recieving such a message from >> another participant -- is this actually a new phone, or is it a wiretap >> injection? should i ask the user about it? should i take action? what >> ction? >> > > In Wire, if Alice has marked each of Bob's device fingerprints as > "verified", then the addition of a new device by Bob results in an > immediate message to Alice. The recommended action is to verify the new > fingerprint out of band, then Alice can mark Bob's new device as > "verified". > > > Generally, I wouldn't expect them to take any action at all. It's a user's > responsibility to ensure that the right number of devices are registered > to their account, just as its common for the number of Web browsers > one has attached to ones Gmail account. > > > Here is a scenario on iOS: > > (1) User is logged into Facebook via Chrome. User is not logged into > Facebook in Safari, to avoid Facebook tracking on non-Facebook websites > visited in Safari. > > (2) User receives FB email notification in Apple email. If user clicks on > a link in the email, it opens in Safari and Facebook *automatically logs > the user in without a password*. > > (3) User then receives FB email notification that they have added a new > device. > > (4) User must now manually log out of Facebook, then click on a tiny close > button on account icon to delete the cookie associated with that user, to > avoid Facebook tracking on non-Facebook websites. That removes (?) the > browser as a known device. > > Each of the individual UX decisions above could make sense in some > contexts, but when combined on iOS where the user cannot choose the browser > in which email links are opened, it leads to an undesirable UX where the > user must invest repeated effort to ensure that the right number of devices > are registered to their account. > > Rich > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --001a11442348a4c531056857b260 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

Sorry, I was in mee= tings over the weekend and missed the fun :)=C2=A0 Let me try to sum up.

tl;dr:=C2=A0 It's an application decision. The p= rotocol should be oriented around per-device keys, but we should also docum= ent the privacy concerns and some approaches to mitigating them.
<= div>
I agree with DKG that we should not hard-code a one-key-= per-device assumption into the protocol.=C2=A0 But at the same time, I don&= #39;t want this group to have to assume the complexity of a protocol to syn= c keys across devices in addition to what it's already got.=C2=A0 And h= as been pointed out, there are some valid reason to want individual device = keys to be exposed in the protocol, e.g., key comparison and device revocat= ion.=C2=A0

Fortunately, we don't have to = make a choice here.=C2=A0 Because the protocol doesn't know whether a l= eaf key is an actual leaf or the root of a subtree, there's a clean int= erface point where applications can make a decision.=C2=A0 You could even i= magine different clients in one group making different decisions.

So I would suggest we do the following:
- No chan= ge to the protocol document
- In the architecture document:
=
=C2=A0 - Lay out the privacy risk that can arise from using per-device= keys
=C2=A0 - Present the two approaches discussed in this threa= d for how to do key sync (explicit sync and sub-trees)

=
That way, the WG's document set will provide guidance to implement= ors about the risks and how to mitigate, without diving into the complexity= of a full protocol.

--Richard

<= /div>


On Mon, Mar 26, 2018 at 10:16 AM, Rich Persaud &= lt;persaur@gmail.com= > wrote:
=
On Mar 24, 2018, at 18:42, Eric Rescorla &= lt;ekr@rtfm.com> w= rote:
On Sat, Mar 2= 4, 2018 at 10:32 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net>= ; wrote:

<= span class=3D"">
Furthermore, it's not clear what a group conversation participant can *do*, security-wise, in the event of recieving such a message from
another participant -- is this actually a new phone, or is it a wiretap
injection?=C2=A0 should i ask the user about it?=C2=A0 should i take action= ?=C2=A0 what
ction?
In Wire, if Alice has marked each of Bob's device fingerpri= nts as "verified", then the addition of a new device by Bob resul= ts in an immediate message to Alice.=C2=A0 The recommended action is to ver= ify the new fingerprint out of band, then Alice can mark Bob's new devi= ce as "verified".=C2=A0


Generally, I wouldn't expect= them to take any action at all. It's a user's
responsibi= lity to ensure that the right number of devices are registered
to= their account, just as its common for the number of Web browsers
one has attached to ones Gmail account.

Here is a scenario on iOS:

(1) User is logged into Facebook via Chrome.=C2=A0 User is not logged into= Facebook in Safari, to avoid Facebook tracking on non-Facebook websites vi= sited in Safari.

(2) User receives FB email notifi= cation in Apple email.=C2=A0 If user clicks on a link in the email, it open= s in Safari and Facebook *automatically logs the user in without a password= *.

(3) User then receives FB email notification th= at they have added a new device.

(4) User must now= manually log out of Facebook, then click on a tiny close button on account= icon to delete the cookie associated with that user, to avoid Facebook tra= cking on non-Facebook websites.=C2=A0 That removes (?) the browser as a kno= wn device.

Each of the individual UX decisions abo= ve could make sense in some contexts, but when combined on iOS where the us= er cannot choose the browser in which email links are opened, it leads to a= n undesirable UX where the user must invest repeated effort to ensure that = the right number of devices are registered to their account.

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


--001a11442348a4c531056857b260-- From nobody Mon Mar 26 14:46:20 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1818E126CF6 for ; Mon, 26 Mar 2018 14:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 1tz5KQXEMszN for ; Mon, 26 Mar 2018 14:46:17 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 03096126CB6 for ; Mon, 26 Mar 2018 14:46:16 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id z8so20360955wrh.7 for ; Mon, 26 Mar 2018 14:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/7PX27/A5ult43GOUbAmn1QFSBXTD0fTyBuZo7go9BU=; b=UI96EetzChCY6rKZStzZUNu4KstphvseJoZa9jt7FnnLSaYHuCg/MzeyuGzTJMnojE JJel/xBXGF0pMpRACkdfNNaemNnBXXBh0vGfsz8GfpTG3q9rCcSovBNH8tbZBMI4C3p5 OgvgnoaBgdOllHW32HeCbbsPttBZEj7HDbA5d5A3F8duZuSIRFKSZyYyY1z/H/P3NmZM e8Po9+RWd8bKpkcHXh5M8BiivnsDQQ8MUQmcotW0hzfL20o2EBEbto7UBoQCCxCRuvQT v1JfSTBaBiPdWe0Vhjcv718WbZURxvLsBAp1XB2l6BvVFg6YpdQxq4aXh+2wGOdSubgF u1jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/7PX27/A5ult43GOUbAmn1QFSBXTD0fTyBuZo7go9BU=; b=RxhyPAzGJUV5kxXNvu3iY5Sm4hENiGEllJ2oVEN7UACtKUnM87ANbGy2rFYip9nhWD j5pZwF6zQYBGvNHD9sjDXMHzA/yJLmXjwP8uPuof+PZ0f1qPt9OUCFyT3livAGYZl3vr Mja13kciKNbt6MgklxP7rvEMrIaYaTY6DURHmraZnV4QQMcwbB4fh1IbplATRG5jm8ri 9F/VSzYxEm51xGWG2soR4OpBfxPW6TRqYyTDzg5MnI2H7IG3ONmSSJWMLWuKYnttTqzP Cnua8HIxv8WPHSNE0xDwrLwMufjD+d1SpX/QCVvg5CD442+Dxr84ew9ghBgYnMxiYHej MuCQ== X-Gm-Message-State: AElRT7HmKCgmAS8//3JKK/a/7/azbY/QRVdY0LRdcYBiBRocSftciKiQ w7Il5WFjHs2jciGEdXhShUqWsLIo9s8FFlJ1qiQ1oQ== X-Google-Smtp-Source: AG47ELvLoXNh+iGrsT5IPfYLG63FSplICsX494Vf705HZpmxyvvq4tRcdjAsiMTaCWM7QuTGNTEAt5jTHNYFPwLxcuk= X-Received: by 10.223.135.83 with SMTP id 19mr17485956wrz.150.1522100775454; Mon, 26 Mar 2018 14:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Mon, 26 Mar 2018 14:46:14 -0700 (PDT) In-Reply-To: <29A3652D-76EB-4830-8337-819EE19D597C@gmail.com> References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <29A3652D-76EB-4830-8337-819EE19D597C@gmail.com> From: Richard Barnes Date: Mon, 26 Mar 2018 22:46:14 +0100 Message-ID: To: Rich Persaud Cc: Raphael Robert , mls@ietf.org Content-Type: multipart/alternative; boundary="001a1146c2f8089df4056857b4ba" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2018 21:46:19 -0000 --001a1146c2f8089df4056857b4ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I have some sympathy for DKG's point, I agree with Raphel and Katriel that things are clear enough as-is. In addition, if there's any ambiguity, it should be cleared up by the charter. If we're going to change, I admit that I find MSG pretty appealing. Topical and tasty! On Mon, Mar 26, 2018 at 10:23 AM, Rich Persaud wrote: > On Mar 24, 2018, at 11:25, Raphael Robert wrote: > > We looked at a number of alternatives to MLS and in the end none of them > seemed to be substantially better than =E2=80=9CMessaging Layer Security= =E2=80=9D, but that > doesn=E2=80=99t mean the name cannot be changed. > > > There is potential for collision with the MLS acronym that has been used > for years (decades?), especially when combined with search terms like > "security" or "cryptography": https://en.wikipedia.org/ > wiki/Multilevel_security > > > Rich > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --001a1146c2f8089df4056857b4ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I have some sympathy for DKG's point, I agr= ee with Raphel and Katriel that things are clear enough as-is.=C2=A0 In add= ition, if there's any ambiguity, it should be cleared up by the charter= .

If we're going to change, I admit that I fin= d MSG pretty appealing.=C2=A0 Topical and tasty!

On Mon, Mar 26, 2018 at 10:= 23 AM, Rich Persaud <persaur@gmail.com> wrote:
On = Mar 24, 2018, at 11:25, Raphael Robert <raphael@wire.com> wrote:

<= blockquote type=3D"cite">
We looked at a number of alternatives to MLS = and in the end none of them seemed to be substantially better than =E2=80= =9CMessaging Layer Security=E2=80=9D, but that doesn=E2=80=99t mean the nam= e cannot be changed.

There is potential f= or collision with the MLS acronym that has been used for years (decades?), = especially when combined with search terms like "security" or &qu= ot;cryptography": =C2=A0https://en.wikipedia.org/wiki/Mult= ilevel_security

Rich

________________________= _______________________
MLS mailing list
MLS@ietf.org
https://www.ietf.org/mailman/listinfo/mls


--001a1146c2f8089df4056857b4ba-- From nobody Tue Mar 27 14:01:05 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DA0127867 for ; Tue, 27 Mar 2018 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbEN3rcWdS4h for ; Tue, 27 Mar 2018 14:01:01 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C2312D874 for ; Tue, 27 Mar 2018 14:01:01 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 7CEA8F99B; Tue, 27 Mar 2018 17:01:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0DF472098F; Tue, 27 Mar 2018 16:55:00 -0400 (EDT) From: Daniel Kahn Gillmor To: Nadim Kobeissi , Suhas Nandakumar Cc: mls@ietf.org, Raphael Robert In-Reply-To: <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> Date: Tue, 27 Mar 2018 16:54:56 -0400 Message-ID: <87370lkzmn.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 21:01:03 -0000 --=-=-= Content-Type: text/plain On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote: > I do not believe the name should be changed: > > 1. MLS is a protocol that is equally suited for pairwise messaging as it is for group messaging > 2. The MLS name is elegant and mirrors TLS. "Mirroring TLS" is exactly what i'm afraid of. This is a radically different protocol, performing demonstrably different work at a different position within the stack, with a different view on what interoperability even means. Let's make it very clear that this *is not* TLS, and that it is not a substitute for TLS. The protocol described in the documents is *not* equally-suited for pairwise messaging -- it has a number of subtle features that are included solely because it is intended to handle group messaging. As other people have written upthread, the protocol this nascent WG aims to describe will handle pairwise messaging as a special case of group messaging. It is not designed intentionally for pairwise messaging and if it were, it would have a different design. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTTaP514aqS9uSbmdJsHx7ezFD6UwUCWrqvoAAKCRBsHx7ezFD6 U3iMAP4zuh8eoPhN23z7o6AojPLr5rH//YwWHbyycwKztbqIHAEAt6waNTsff8W0 OkvVWK0qDmE74gTATSstlPY3mx5nngQ= =Q6aM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 27 14:01:09 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CEC127867 for ; Tue, 27 Mar 2018 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-_2V-A4q_55 for ; Tue, 27 Mar 2018 14:01:02 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8552B12D940 for ; Tue, 27 Mar 2018 14:01:01 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6C824F99A; Tue, 27 Mar 2018 17:01:00 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EA08E20A0B; Tue, 27 Mar 2018 16:56:57 -0400 (EDT) From: Daniel Kahn Gillmor To: Justin Uberti , Eric Rescorla Cc: mls@ietf.org In-Reply-To: References: <87efk9m7e9.fsf@fifthhorseman.net> Date: Tue, 27 Mar 2018 16:56:57 -0400 Message-ID: <87zi2tjkyu.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 21:01:04 -0000 On Sat 2018-03-24 22:52:48 +0000, Justin Uberti wrote: > Also, allowing exfiltration of keys in order to allow cross-device sharing > seems to introduce its own set of problems. it's not clear that any protocol can prevent key exfiltration from an endpoint that wants to exfiltrate keys outside of that protocol. so i don't think it's a question of "allowing" here. --dkg From nobody Tue Mar 27 14:17:40 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347FD12D874 for ; Tue, 27 Mar 2018 14:17:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 mYnPqeeByS6F for ; Tue, 27 Mar 2018 14:17:36 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7FF127867 for ; Tue, 27 Mar 2018 14:17:36 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id r131so1389204wmb.2 for ; Tue, 27 Mar 2018 14:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lPioVKLppbDTXGWGMiA938wE8sHwGWEjaLWQ21ojkgs=; b=nHeTpSjMKOJtAqgSLK42bS7HcIL/4VhE1I+5y1TX3MFQvP6wxVgWIqT7kWdL/x48q5 EHYuNbfLKMnK4rCuEE7Z2uTmHNHDFI7GEQfgI9qMWPB3eNiHcduwV56fjG6NBj68Zl3j SDqKNxSzjhtbHHD49yh0mlqFDuYpv5AKjVTwtvrm71oHsLm6/JwtQ9PXMbMOLyACX9ff ereB3pgctnRAWqpClNMOwqQ6OjeTQ5Cw2tzrkCRRZZYpvw1YWmkAwfuk883KcjbKzOHW fkfk7iUuIBnOqoPLj5QMz6IBLhg7trayQ+mGio2rVwZDWfkO2sj8gbTikxxhsSXaymLu 5O7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lPioVKLppbDTXGWGMiA938wE8sHwGWEjaLWQ21ojkgs=; b=G9cG2/29lOHxlg4wJg2giQfkW82yJcqu9dIrzHiacaZzgFkjbkHOpkPg1Tsb7BVv9D ddgQsnmqhddTvR5Yv9f7fvFX+Czc5AP/QDPevQLiANgmIQD/8APjvxUXt6BhrX29IJih eilMmGCRXj1i7FvvWtqAC08uBjdzr0R9aGI1zAEZdVQttzlh0Sj90kNrfCd8ij349msd c2OWZr0MzR3lyV5sXU5KM2IOJLpdJtnpc1horkuHNtm/QJN3tOIRiXGCGINjxiKCV9Rs eUDvJjqH4M4HCG+7b33zHUAmKgo8VOuhrRuVm+xcxVYbBZF+9DIsANm2p5CmBiQpNcuU Ve9w== X-Gm-Message-State: AElRT7HyB3nqGCG3V2LZ9k2f4PTwAnfRYXbHZjmwu3pnobmtx75e3DDN pxpPWJk3cxetw9yQxx/HVWkdzYZDw2aBHwwV4dbehF2g X-Google-Smtp-Source: AIpwx4/jIYv++EAGdACvz0tsnTlZcBydrwdctHZswiaUU4pl/5ZzsfK7qMJKaU1kziSzZp7vYDTTvUyGWYe44hEladE= X-Received: by 10.28.21.77 with SMTP id 74mr657107wmv.76.1522185455013; Tue, 27 Mar 2018 14:17:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.12.140 with HTTP; Tue, 27 Mar 2018 14:17:34 -0700 (PDT) In-Reply-To: <87370lkzmn.fsf@fifthhorseman.net> References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> From: Richard Barnes Date: Tue, 27 Mar 2018 21:17:34 +0000 Message-ID: To: Daniel Kahn Gillmor Cc: Nadim Kobeissi , Suhas Nandakumar , mls@ietf.org, Raphael Robert Content-Type: multipart/alternative; boundary="001a1145b11654236a05686b6b9f" Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 21:17:39 -0000 --001a1145b11654236a05686b6b9f Content-Type: text/plain; charset="UTF-8" On Tue, Mar 27, 2018 at 8:54 PM, Daniel Kahn Gillmor wrote: > On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote: > > I do not believe the name should be changed: > > > > 1. MLS is a protocol that is equally suited for pairwise messaging as it > is for group messaging > > 2. The MLS name is elegant and mirrors TLS. > > "Mirroring TLS" is exactly what i'm afraid of. This is a radically > different protocol, performing demonstrably different work at a > different position within the stack, with a different view on what > interoperability even means. > > Let's make it very clear that this *is not* TLS, and that it is not a > substitute for TLS. > > The protocol described in the documents is *not* equally-suited for > pairwise messaging -- it has a number of subtle features that are > included solely because it is intended to handle group messaging. As > other people have written upthread, the protocol this nascent WG aims to > describe will handle pairwise messaging as a special case of group > messaging. It is not designed intentionally for pairwise messaging and > if it were, it would have a different design. > I'm surprised by this claim. Signal protocol is designed for 1-1 messaging, and with the current draft, a 2-party session is pretty much the same as a Signal session. ISTM the difference between MLS(n=2) and TLS is driven more by the desire for asynchronicity than by the optimization for groups. Which might lead one to argue that "asynchronous" should be in the name, but the same "because it's 2018" argument applies. --Richard > > --dkg > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > > --001a1145b11654236a05686b6b9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Mar 27, 2018 at 8:54 PM, Daniel Kahn Gillmor = <dkg@fifthhor= seman.net> wrote:
On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote:
> I do not believe the name should be changed:
>
> 1. MLS is a protocol that is equally suited for pairwise messaging as = it is for group messaging
> 2. The MLS name is elegant and mirrors TLS.

"Mirroring TLS" is exactly what i'm afraid of.=C2=A0 T= his is a radically
different protocol, performing demonstrably different work at a
different position within the stack, with a different view on what
interoperability even means.

Let's make it very clear that this *is not* TLS, and that it is not a substitute for TLS.

The protocol described in the documents is *not* equally-suited for
pairwise messaging -- it has a number of subtle features that are
included solely because it is intended to handle group messaging.=C2=A0 As<= br> other people have written upthread, the protocol this nascent WG aims to describe will handle pairwise messaging as a special case of group
messaging.=C2=A0 It is not designed intentionally for pairwise messaging an= d
if it were, it would have a different design.

I'm surprised by this claim.=C2=A0 Signal protocol is designed f= or 1-1 messaging, and with the current draft, a 2-party session is pretty m= uch the same as a Signal session.

ISTM the dif= ference between MLS(n=3D2) and TLS is driven more by the desire for asynchr= onicity than by the optimization for groups.=C2=A0 Which might lead one to = argue that "asynchronous" should be in the name, but the same &qu= ot;because it's 2018" argument applies.

--Richard

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg

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


--001a1145b11654236a05686b6b9f-- From nobody Tue Mar 27 14:47:12 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808D912DA51 for ; Tue, 27 Mar 2018 14:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVNiDcyAZf2b for ; Tue, 27 Mar 2018 14:47:09 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33EDD124234 for ; Tue, 27 Mar 2018 14:47:09 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id E17FFF99A; Tue, 27 Mar 2018 17:47:07 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id EEB0C2076E; Tue, 27 Mar 2018 17:45:04 -0400 (EDT) From: Daniel Kahn Gillmor To: Richard Barnes Cc: Nadim Kobeissi , Suhas Nandakumar , mls@ietf.org, Raphael Robert In-Reply-To: References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> Date: Tue, 27 Mar 2018 17:45:04 -0400 Message-ID: <87lgedjiqn.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 21:47:10 -0000 On Tue 2018-03-27 21:17:34 +0000, Richard Barnes wrote: > I'm surprised by this claim. Signal protocol is designed for 1-1 > messaging, and with the current draft, a 2-party session is pretty much the > same as a Signal session. Sure, so we don't need the tree at all in that case, right? similarly, we don't need message signatures (which Signal doesn't have). i get it that the 2-party protocol can be treated as a special case of the n-party protocol. that doesn't mean we're designing a two-party protocol, though. We're clearly designing a group messaging protocol, and we should say so. > ISTM the difference between MLS(n=2) and TLS is driven more by the desire > for asynchronicity than by the optimization for groups. Which might lead > one to argue that "asynchronous" should be in the name, but the same > "because it's 2018" argument applies. Asynchronous messaging predates the present moment by at least 36 years (c.f. RFC 821) -- it's not a novel 2018 requirement :P --dkg From nobody Tue Mar 27 16:02:48 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFA1126CB6 for ; Tue, 27 Mar 2018 16:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_NUMERIC_HELO=1.164, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 GlE7qvi2HrQ2 for ; Tue, 27 Mar 2018 16:02:46 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 12D9B124B18 for ; Tue, 27 Mar 2018 16:02:46 -0700 (PDT) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 161C91E0A0D for ; Tue, 27 Mar 2018 17:02:39 -0600 (MDT) Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id TB2b1x00J2UhLwi01B2eqL; Tue, 27 Mar 2018 17:02:39 -0600 X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=IkcTkHD0fZMA:10 a=v2DPQv5-lfwA:10 a=skbIlk6SAAAA:8 a=zfccQYhVbGtIfRN0bH8A:9 a=QEXdDO2ut3YA:10 a=P5SZwATmzn4K3VfFWgKo:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:In-Reply-To: References:Subject:Cc:To:From:Message-ID:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lzoOLEYHzIaosns+z1jGLd1uX3mCo6kxAw4RDdhVOoQ=; b=CRk6QBeidTJDH8Gm3mDz+xOR+ r2IUmG3tKz/qjdLV+2qKmnIm7+PgvdxgpyCBgS+lyNIV7AtX1PiWQ5sjgjhKg5szFHDVzFsVyRCth WCIjKX2PebWl2n+qwwdiM6jyxX; Received: from [127.0.0.1] (port=39109 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1f0xbv-0019Y2-0I; Tue, 27 Mar 2018 17:02:35 -0600 Received: from 67.188.157.169 ([67.188.157.169]) by box514.bluehost.com (Horde Framework) with HTTPS; Tue, 27 Mar 2018 17:02:34 -0600 Date: Tue, 27 Mar 2018 17:02:34 -0600 Message-ID: <20180327170234.Horde.43MSPLLX_Qj2qLxxX-UUuL3@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Daniel Kahn Gillmor Cc: Nadim Kobeissi , Suhas Nandakumar , mls@ietf.org, Raphael Robert References: <87r2o9n277.fsf@fifthhorseman.net> <1521900339.2114148.1314586920.36507FA3@webmail.messagingengine.com> <6A75C740-6759-448D-9BC8-17A459D5F36E@symbolic.software> <87370lkzmn.fsf@fifthhorseman.net> In-Reply-To: <87370lkzmn.fsf@fifthhorseman.net> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Exim-ID: 1f0xbv-0019Y2-0I X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:39109 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [MLS] MLS: the WG name should include "group" X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 23:02:47 -0000 +1 Quoting Daniel Kahn Gillmor : > On Sun 2018-03-25 21:33:42 +0200, Nadim Kobeissi wrote: >> I do not believe the name should be changed: >> >> 1. MLS is a protocol that is equally suited for pairwise messaging >> as it is for group messaging >> 2. The MLS name is elegant and mirrors TLS. > > "Mirroring TLS" is exactly what i'm afraid of. This is a radically > different protocol, performing demonstrably different work at a > different position within the stack, with a different view on what > interoperability even means. > > Let's make it very clear that this *is not* TLS, and that it is not a > substitute for TLS. > > The protocol described in the documents is *not* equally-suited for > pairwise messaging -- it has a number of subtle features that are > included solely because it is intended to handle group messaging. As > other people have written upthread, the protocol this nascent WG aims to > describe will handle pairwise messaging as a special case of group > messaging. It is not designed intentionally for pairwise messaging and > if it were, it would have a different design. > > --dkg From nobody Tue Mar 27 16:41:14 2018 Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5095D124B18 for ; Tue, 27 Mar 2018 16:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UgOUgpdIZS-Z for ; Tue, 27 Mar 2018 16:41:10 -0700 (PDT) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::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 6CD5D1200C1 for ; Tue, 27 Mar 2018 16:41:10 -0700 (PDT) Received: by mail-ua0-x244.google.com with SMTP id u4so399906uaf.10 for ; Tue, 27 Mar 2018 16:41:10 -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=RE0D3UXi2JMDXmUpZxPzH7Ujjpqwacc0VMOjQ13XyaY=; b=SV2haaEScmgG1JYyJTnvoVTHCA3jdOrusFJHjiNlV11TkXolB75jaofaQpNkIqrLrp jhdxwfox+cbtAVArfZA01vjq4ytxXuw8ramxGAdwobex+qG/zbosFWUkS2UVn408fwTw x7Ij2aATkyiD0QXtYQJhJFjV49JhZBgijuWsAMO/O+MZcx6x256iLWgVAsBpY1ag5xls FtoB69CAEYKd9bWj0qh04LgOuC1PzQjTK0Y/rRyDwXkwfDluO9M6Txkrw1NIEOgMI9hL fpTb9PjbGqE1KLeZyLg8O3m5Pd0puDbnY1kS5sBqcw5p49b5JaPjmos6Fb3KJccuYeFr lZMw== 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=RE0D3UXi2JMDXmUpZxPzH7Ujjpqwacc0VMOjQ13XyaY=; b=JIljzxjWlfUWw59xlr+0HItZbytedlEljVpr9VfAvMW+W+QUu04xADr0eRvIqYHo++ jce5LyhLb5BWrLN4viiv4aW7e7sUJrohp/8PsZySI3C+2wXDyF5mhjadBcUlfvY0Jw/7 GM9415YxN/43i0NsZt2d9R5JREnUoiX1vYiCG4urDJ1njTnCnyfSNCDmhj5nqTfPgTk9 ThFguRIwK8Rq2qMMs+XpzRZZ4XVlgk1WmSLFTpw0SNbvQFPUOg+lUU0OU4ANs3BplsDc dgU5etQanWvgHaoX1Rp3niN9JJVT1jYv8Kp33UJjQW3zKH9HDN/e3xE4/aR0ncF1EmAI cvQQ== X-Gm-Message-State: AElRT7Ez6z1CnB0JqcVdUKcTCn1B3U99DUJ741c6TQGlhYL3lv8jHF+h FEI1gKrNeaJvMxQNsHslMeLlb7FyI/Ku2ScQW1Z0fw== X-Google-Smtp-Source: AIpwx48If2RMo1sLMmLi0T9K0UjEvRxRVcElOIoWmE3O7X3lRYiToRMiKuWPjWxYSCd5RBtkQsQXIHLV0PDx1prZRu0= X-Received: by 10.159.32.72 with SMTP id 66mr1070101uam.72.1522194068907; Tue, 27 Mar 2018 16:41:08 -0700 (PDT) MIME-Version: 1.0 References: <87efk9m7e9.fsf@fifthhorseman.net> <87zi2tjkyu.fsf@fifthhorseman.net> In-Reply-To: <87zi2tjkyu.fsf@fifthhorseman.net> From: Justin Uberti Date: Tue, 27 Mar 2018 23:40:58 +0000 Message-ID: To: dkg@fifthhorseman.net Cc: Eric Rescorla , mls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c03f7b8c2200505686d6c16" Archived-At: Subject: Re: [MLS] multiple devices per user? X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 23:41:12 -0000 --94eb2c03f7b8c2200505686d6c16 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 27, 2018 at 2:01 PM Daniel Kahn Gillmor wrote: > On Sat 2018-03-24 22:52:48 +0000, Justin Uberti wrote: > > Also, allowing exfiltration of keys in order to allow cross-device > sharing > > seems to introduce its own set of problems. > > it's not clear that any protocol can prevent key exfiltration from an > endpoint that wants to exfiltrate keys outside of that protocol. so i > don't think it's a question of "allowing" here. > There are hardware architectures (e.g. Secure Enclave) where key material can be used for encryption but the raw private key cannot be extracted. If the protocol requires access to the key in order to enroll a new device, this reduces the efficacy of the hardware mechanism (or may not work at all). Overall, I agree with Richard on this - it's an application decision. There are some niceties associated with a single key per user, but this will not be an option in all circumstances. --94eb2c03f7b8c2200505686d6c16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On= Tue, Mar 27, 2018 at 2:01 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
On Sat 2018-03-24 22:52:48 +0000, Justin Uberti wrote= :
> Also, allowing exfiltration of keys in order to allow cross-device sha= ring
> seems to introduce its own set of problems.

it's not clear that any protocol can prevent key exfiltration from an endpoint that wants to exfiltrate keys outside of that protocol.=C2=A0 so i=
don't think it's a question of "allowing" here.

There are hardware architectures (e.g. Secure En= clave) where key material can be used for encryption but the raw private ke= y cannot be extracted. If the protocol requires access to the key in order = to enroll a new device, this reduces the efficacy of the hardware mechanism= (or may not work at all).

Overall, I agree with R= ichard on this - it's an application decision. There are some niceties = associated with a single key per user, but this will not be an option in al= l circumstances.
--94eb2c03f7b8c2200505686d6c16--