Subject: Re: [MLS] [new-work] WG Review: Messaging Layer Security (mls)

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 May 2018 09:55:56 -0600

Two points:

1. It would be helpful to specify the expected capabilities of devices
on which the resulting protocol might be deployed, such as only personal
devices (e.g., phones and tablets) or also Internet of Things devices.
If IoT devices are in scope (I hope they are!), then citing RFC 7228
would be good:

https://datatracker.ietf.org/doc/rfc7228/

2. Instead of referring to Signal, I suggest that we talk about double
ratchet algorithms, because Signal is an instance of the latter and
there are many other instances:

https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm

Peter

On 5/14/18 8:04 AM, The IESG wrote:
> A new IETF WG has been proposed in the Security Area. The IESG has not made
> any determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list ([email-masked]) by 2018-05-23.
> 
> Messaging Layer Security (mls)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>   Nick Sullivan <[email-masked]>
>   Sean Turner <[email-masked]>
> 
> Assigned Area Director:
>   Benjamin Kaduk <[email-masked]>
> 
> Security Area Directors:
>   Eric Rescorla <[email-masked]>
>   Benjamin Kaduk <[email-masked]>
> 
> Mailing list:
>   Address: [email-masked]
>   To subscribe: https://www.ietf.org/mailman/listinfo/mls
>   Archive: https://mailarchive.ietf.org/arch/browse/mls/
> 
> Group page: https://datatracker.ietf.org/group/mls/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-mls/
> 
> Several Internet applications have a need for group key establishment
> and message protection protocols with the following properties:
> 
> o Message Confidentiality - Messages can only be read
>   by members of the group
> o Message Integrity and Authentication - Each message
>   has been sent by an authenticated sender, and has
>   not been tampered with
> o Membership Authentication - Each participant can verify
>   the set of members in the group
> o Asynchronicity - Keys can be established without any
>   two participants being online at the same time
> o Forward secrecy - Full compromise of a node at a point
>   in time does not reveal past messages sent within the group
> o Post-compromise security - Full compromise of a node at a
>   point in time does not reveal future messages sent within the group
> o Scalability - Resource requirements have good scaling in the
>   size of the group (preferably sub-linear)
> 
> Several widely-deployed applications have developed their own
> protocols to meet these needs. While these protocols are similar,
> no two are close enough to interoperate. As a result, each application
> vendor has had to maintain their own protocol stack and independently
> build trust in the quality of the protocol. The primary goal of this
> working group is to develop a standard messaging security protocol
> so that applications can share code, and so that there can be shared
> validation of the protocol (as there has been with TLS 1.3).
> 
> It is not a goal of this group to enable interoperability/federation
> between messaging applications beyond the key establishment,
> authentication, and confidentiality services.  Full interoperability
> would require alignment at many different layers beyond security,
> e.g., standard message transport and application semantics.  The
> focus of this work is to develop a messaging security layer that
> different applications can adapt to their own needs.
> 
> While authentication is a key goal of this working group, it is not
> the objective of this working group to develop new authentication
> technologies.  Rather, the security protocol developed by this
> group will provide a way to leverage existing authentication
> technologies to associate identities with keys used in the protocol,
> just as TLS does with X.509.
> 
> In developing this protocol, we will draw on lessons learned from
> several prior message-oriented security protocols, in addition to
> the proprietary messaging security protocols deployed within
> existing applications:
> 
> o S/MIME - https://tools.ietf.org/html/rfc5751
> o OpenPGP - https://tools.ietf.org/html/rfc4880
> o Off the Record - https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
> o Signal - https://signal.org/docs/
> 
> The intent of this working group is to follow the pattern of
> TLS 1.3, with specification, implementation, and verification
> proceeding in parallel.  By the time we arrive at RFC, we
> hope to have several interoperable implementations as well
> as a thorough security analysis.
> 
> The specifications developed by this working group will be
> based on pre-standardization implementation and deployment
> experience, generalizing the design described in:
> 
> o draft-omara-mls-architecture
> o draft-barnes-mls-protocol
> 
> Note that consensus is required both for changes to the current
> protocol mechanisms and retention of current mechanisms. In
> particular, because something is in the initial document set does
> not imply that there is consensus around the feature or around
> how it is specified.
> 
> Milestones:
> 
>   May 2018 - Initial working group documents for architecture and key
>   management
> 
>   Sep 2018 - Initial working group document adopted for message protection
> 
>   Jan 2019 - Submit architecture document to IESG as Informational
> 
>   Jun 2019 - Submit key management protocol to IESG as Proposed Standard
> 
>   Sep 2019 - Submit message protection protocol to IESG as Proposed Standard
> 
> 
> _______________________________________________
> new-work mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/new-work
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 May 2018 07:05:23 -0700

> https://datatracker.ietf.org/doc/rfc7228/

I think the default is we assume reasonably powerful general purpose
computers, so if people want IoT to be designed for -- which it shouldn't,
IMO -- then that would have to be stated in the charter.

-Ekr

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 May 2018 10:22:46 -0600

On 5/24/18 8:05 AM, Eric Rescorla wrote:
> 
> 
> On Mon, May 14, 2018 at 8:55 AM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Two points:
> 
>     <https://datatracker.ietf.org/doc/rfc7228/>
> 
> 
> computers, 

Constrained devices are indeed hard to design for (and there are many
dimensions of constraint - code size, memory, storage, battery, etc.). I
wouldn't necessarily argue for supporting Class 0 devices (which
according to RFC 7228 are "very constrained sensor-like motes"), but
Class 2 devices (which are "fundamentally capable of supporting most of
the same protocol stacks as used on notebooks or servers") would be
great. I'm not sure where to draw the line and whether to include Class
1 devices (which "are quite constrained in code space and processing
capabilities, such that they cannot easily talk to other Internet nodes
employing a full protocol stack such as using HTTP, Transport Layer
Security (TLS), and related security protocols and XML-based data
representations").

> so if people want IoT to be designed for -- which it
> shouldn't, IMO -- then that would have to be stated in the charter.

No matter what we decide, it would be good to make that explicit in the
charter.

Peter

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 26 May 2018 16:46:54 -0500

FWIW,

> No matter what we decide, it would be good to make that explicit in the

I'd agree with Peter in general, but especially in this case - it seems
unhelpful to the working group to make them figure out whether to include
Class 1 devices in their work, after they've been chartered.

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 May 2018 15:18:07 -0700

I think even Class 2 devices should be out of scope. If it happens to be
the case that the protocol works for them, then great, but it shouldn't be
a design consideration.

More to the point, I don't really understand why this needs to be in the
charter. Again, the default assumption should be that devices aren't
constrained; if each charter is going to need to say that, we're going to
need to revise a lot of WG charters.

-Ekr

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 28 May 2018 09:39:54 -0500

Hi, Eric,

> need to revise a lot of WG charters.

I agree that charters don't need to include a mention of everything that is
out of scope - not only would we be revising a lot of WG charters, but the
revised chartered would be really long (and for extra credit, we could read
them aloud as children's books, because they would sound a lot like "Green
Eggs and Ham"(*)).

I do think it makes sense to include topics that have come up in chartering
discussions, especially if the resulting answer was "no, we're not gonna do
that", because some working group participants can be really sure that that
thing we decided not to do was really the right thing to do after all, and
being able to point to the charter can make life easier for chairs and ADs.

That's why I commented about this.

Do the right thing, of course ...

Spencer

(*) for those who don't know "Green Eggs and Ham", it's a children's book,
and an excerpt is at
https://genius.com/Dr-seuss-green-eggs-and-ham-excerpt-annotated. The
complete book is much more endless than the excerpt would make you think -
endless enough that my junior senator, the Savior Of IANA IPR Except Not,
read the book aloud to the assembled senate during a filibuster in 2013.
YouTube is at https://www.youtube.com/watch?v=q8-NuwTjtq4.