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 1ADB31310FE for ; Wed, 13 Mar 2019 12:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 (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 SI7umPVsXljx for ; Wed, 13 Mar 2019 12:08:56 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 105B01310E7 for ; Wed, 13 Mar 2019 12:08:53 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id p17so2700948iol.7 for ; Wed, 13 Mar 2019 12:08:53 -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=Kn9tB/hcWAHY9EY/CR1VX/kqjl9PF9TwTpMH1LnlgCw=; b=QhqITJXmb9fa1Q63Jv5zv5pV0vHpsK4LU0j95NkSmm0sphbpi5niX6MnfnJUVCH405 AWG+u72H+FtXxNNRiMKqNq9uaqF4pi6GrVA/bln2QsMi5+yXw1wMelBCpe0abssnxFv0 iKi1SfXBigcmU/lm/2svgBgdVrtD2YymVXL71ThxlxB17WsAyc+0U2r6mx2TRIufg7PN QoFjxNrTGAlDsgqnrm5eR0D9TvQSTv3rJOBKEgIhYsDnF5N11GXF0OVEGjDfXuZlvwhv kE1sxuAd3wLnZ7O96sc6c2jpHCeMLg8FNAWYvNoXrcU52+iCSCFLGffmdgmk7purKEQK k16Q== 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=Kn9tB/hcWAHY9EY/CR1VX/kqjl9PF9TwTpMH1LnlgCw=; b=oOuLOpamaPnKAbt5+LeMRzsWt+yMCmH4qShjRcTSR6kMJMzY4TOSZgJPuRpPAUSIY1 a1Cqr1Qh5R4JMs6qKIRzt0SIIR2ld6cygrvl3F73iFibbhJTaE35kJC+E3l+Y/KtryBe AnxjcpJwgRj6TrkJGFQQyGDkO/p6BdYQbxoVWKMAA9IAvxiMAkxg0QgEmJzlG3Pm7lYx 5hxkpqNthpMV69FCG7F4f4KY9wktX8b7m+2LN0BmUhUv3Y5KGKokb2PbDnDaRbxC4V4B BRPnObWaz9ewW22Iu0IohozWSuDiMu0B6RaT8QF8rSq5qnUBZdLceNC9wqS6L+UujtHl 7vdA== X-Gm-Message-State: APjAAAUPTU2EucQge2I2FMnSn7Vgj08IiHn1I+k9lBdlBzpYJKiD8Gub 0oeRMeJiLvsVBzcTtnhS38t6AkKOufwgDHFZRe0= X-Google-Smtp-Source: APXvYqx4MnwKTnQas6FeIxkrYIVzdPLiDglnzE11c41Q/34j86X4wNDo448FqByryVP4iXXhIy7Y2zLCfoheZAD+NZ4= X-Received: by 2002:a6b:710d:: with SMTP id q13mr2587167iog.145.1552504132145; Wed, 13 Mar 2019 12:08:52 -0700 (PDT) MIME-Version: 1.0 References: <155231947405.23094.13317482052323839515@ietfa.amsl.com> In-Reply-To: From: Ted Hardie Date: Wed, 13 Mar 2019 12:08:25 -0700 Message-ID: To: Sean Turner Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000004f19520583fe890a" Archived-At: Subject: Re: [MLS] Fwd: I-D Action: draft-omara-mls-federation-00.txt X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 19:08:59 -0000 --0000000000004f19520583fe890a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Howdy, I found one of the use cases a bit confusing. The text says: 3.2. Different client applications Different client applications operated by the same server can use MLS to exchange E2EE handshake and application messages. For example different browsers can implement the MLS protocol, and web developers write web applications that use the MLS implementation in the browser to encrypt and decrypt the messages. This will require a new standard Web API to allow the client applications to set the address of the delivery service in the browser. A more concrete example is using MLS in the browser to exchange SRTP keys for multi-party conference call. It wasn't clear to me whether the intent was to cover single entities who have multiple client applications (e.g. a phone and browser sharing state on an exchange for a single user) or to cover the case where different client applications wanted to exchange messages for different users (the multi-party conference call among users on phones and different browsers). Given the overall topic, I assume that the first of these is covered here and that the second is more basic to MLS, but it might be useful to revise the text here to clarify. regards, Ted Hardie On Wed, Mar 13, 2019 at 11:56 AM Sean Turner wrote: > At the interim in January, the WG discussed the possibility of adopting > work to address federations. Part of that process is to consider and > individual draft first and then do a WG call for adoption. Emad promised > to get a draft in before the deadline and he and Raphael met the deadline= . > They did their bit so now it is time for the WG to discuss the draft. We > have tentatively allocated some time on the agenda for this draft on the > assumption that it will generate some discussion based on the amount of > interest at the interim. > > Note that this =E2=80=9Cfederation=E2=80=9D we are talking about here is = only about > federating some/all of the key establishment, authentication, and > confidentiality services because this would be in scope of the WG. > > spt > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **I-D Action: draft-omara-mls-federation-00.txt* > *Date: *March 11, 2019 at 11:51:14 EDT > *To: * > *Reply-To: *internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The Messaging Layer Security (MLS) Federation > Authors : Emad Omara > Raphael Robert > Filename : draft-omara-mls-federation-00.txt > Pages : 8 > Date : 2019-03-11 > > Abstract: > This document describes how the Messaging Layer Security (MLS) can be > used in a federated environment where different MLS implementations > can interoperate by defining the message format for user key > retrieval. The document also describes some use cases where > federation could be useful. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-omara-mls-federation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-omara-mls-federation-00 > https://datatracker.ietf.org/doc/html/draft-omara-mls-federation-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > MLS mailing list > MLS@ietf.org > https://www.ietf.org/mailman/listinfo/mls > --0000000000004f19520583fe890a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

I found one of the us= e cases a bit confusing.=C2=A0 The text says:


= 
3.2.  Different client applicatio=
ns

   Different client applications operated by the same server can use MLS
   to exchange E2EE handshake and application messages.  For example
   different browsers can implement the MLS protocol, and web developers
   write web applications that use the MLS implementation in the browser
   to encrypt and decrypt the messages.  This will require a new
   standard Web API to allow the client applications to set the address
   of the delivery service in the browser.  A more concrete example is
   using MLS in the browser to exchange SRTP keys for multi-party
   conference call.

It wasn't clear to me whether the intent was to cover single ent=
ities=20
who have multiple client applications (e.g. a phone and browser sharing=20
state on an exchange for a single user) or to cover the case where=20
different client applications wanted to exchange messages for different=20
users (the multi-party conference call among users on phones and=20
different browsers).=C2=A0=C2=A0=C2=A0 Given the overall topic, I assume th=
at the first=20
of these is covered here and that the second is more basic to MLS, but=20
it might be useful to revise the text here to clarify.
regards,
= 
Ted Hardi=
e


On Wed, Mar 13, 2019 at 11:56 AM Sea= n Turner <sean@sn3rd.com> wrote= :
At the interim in January, the WG discussed the= possibility of adopting work to address federations.=C2=A0 Part of that pr= ocess is to consider and individual draft first and then do a WG call for a= doption.=C2=A0 Emad promised to get a draft in before the deadline and he a= nd Raphael met the deadline.=C2=A0 They did their bit so now it is time for= the WG to discuss the draft.=C2=A0 We have tentatively allocated some time= on the agenda for this draft on the assumption that it will generate some = discussion based on the amount of interest at the interim.

Note that this =E2=80=9Cfederation=E2=80=9D we are talking about here is= only about federating some/all of the=C2=A0key establishment,=C2=A0authent= ication, and confidentiality services because this would be in scope of the= WG.

spt

= Begin forwarded message:

Subject: I-D= Action: draft-omara-mls-federation-00.txt
Date: Ma= rch 11, 2019 at 11:51:14 EDT


A New I= nternet-Draft is available from the on-line Internet-Drafts directories.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: The Messaging Layer Security= (MLS) Federation
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Emad Omara
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Raphael Robe= rt
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0: draft-omara-mls-federation-00.txt
Pages = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 8
Date =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: 2019-03-11

Abstract:
=C2=A0=C2=A0This document des= cribes how the Messaging Layer Security (MLS) can be
=C2=A0=C2=A0used i= n a federated environment where different MLS implementations
=C2=A0=C2= =A0can interoperate by defining the message format for user key
=C2=A0= =C2=A0retrieval.=C2=A0 The document also describes some use cases where
= =C2=A0=C2=A0federation could be useful.


The IETF datatracker st= atus page for this draft is:
https://datatracker.ietf.or= g/doc/draft-omara-mls-federation/

There are also htmlized versio= ns available at:
https://tools.ietf.org/html/draft-omara-ml= s-federation-00
https://datatracker.ietf.org/= doc/html/draft-omara-mls-federation-00


Please note that it m= ay take a couple of minutes from the time of submission
until the htmliz= ed version and diff are available at tools.ietf.org.

Internet-Drafts are also available= by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

____________= ___________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Inter= net-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/= 1shadow-sites.txt

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