Re: [Keytrans] Draft Charter

[Roman Danyliw <[e-mail]>]

Hi!

Brendan: thank you for taking the next formal step after the BoF in Yokohama to draft a charter based on the feedback from that meeting and from the ensuing mailing list conversation.  It is exactly what was needed.

Also, thanks to those that have already given it a review on the list.

Below is mix of feedback I have based on my review; repeating items raised at the BoF or residual to the discussion already on the list; and calling out a few items I know have snagged prior charter approvals in the IESG.

==[ snip ]==

> Public keys in end-to-end encrypted systems are often authenticated solely by

> the assertion of the communications service provider. As a result, the

> underlying encryption protocols are left vulnerable to eavesdropping and

> impersonation by active attackers, in particular the service provider itself,

> which can distribute malicious public keys to selectively gain access to

> communication. Similarly, a malicious service provider could take advantage of

> its privileged network position to launch a number of other attacks, such as:



Given the lack of consensus on the definition of an “end-to-end encrypted system”, I could see this framing snagging the charter review process.  Since this introductory paragraph be restated in the context of a “communications service provider”?  Perhaps:



NEW

Public keys used to provide end-to-end encrypted communication services are often authenticated solely by the assertions of the underlying service provider.  As a result, the underlying encryption protocol used by this service are left vulnerable …



Later in the text the proposed scoping is “an end-to-end encrypted system for human-to-human(s) communication”.  Should that language be used here?



> - Silently partitioning a group, thereby selectively excluding some members of a

> group communication from the rest.

> - Falsifying information about the state of a group, allowing it to eavesdrop on

> messages sent by new joiners.



Is the protocol developed by KEYTRANS WG expected to mitigate these threats?



> To prevent these attacks, end-to-end encrypted service providers are



Nit. Is it “end-to-end encrypted service provider” or “end-to-end encrypted communication service provider”?



> increasingly looking for a way to authenticate information about artifacts in

> their system. These artifacts include end-user accounts or specific group chats,

> where the service provider may wish to authenticate a user’s long-term identity

> key or the state/membership of a group. This authentication scheme must be:



I appreciate that this text was edited based on list feedback.  I’m stuck on the vagueness of the abstraction of “artifacts”.  Walking out of the BoF, I was under the impression this work was largely about some identifier + public key + (maybe) additional meta data.  Are we now potentially talking about a protocol to trade arbitrary data (no public key information) – the notional working title of the WG is “_key_ transparency”?  I can see how using “artifact” would cover all cases, but it also leaves an overly broad scope.  Could the definition be constrained even more in some way?



> User-friendly: Little (ideally zero) user action, or even awareness of the system,

> is required to achieve the authenticity guarantees.



-- Out of the IETF 116 BoF, it seemed like there was support for the “contact monitoring” deployment model per slide 6 of https://datatracker.ietf.org/meeting/116/materials/slides-116-keytrans-example-approach-from-brendan-mcmillion-01.  This “user-friendly” property doesn’t suggest to me that there will be an API of sorts for the user to perform first party checking of their public key.



-- If the user awareness is no longer a consideration, can this text be more specific on who is the authenticity check is for?



> Private: The service provider is able to enforce access control policies such that

> the existence of a specific artifact or its associated data is only revealed by the

> service provider’s explicit choice.



Is it possible to decouple the entity providing the key transparency with the communication service provider?  This text makes it seem like it is one thing.  Do we know right now (without trying to engineering things in the charter) that there should be this flexibility?



> Efficient: The computational requirements for both end-users and the service

> provider scales sub-linearly with the number of users in the system.



-- What is an “end-user” in this context?  Is this an application?



-- Is this “service provider” the “communication service provider” mentioned in the first paragraph?



> Sustainable: Data that’s no longer required by end-users may eventually stop

> being stored.



This sustainability seems like a great end-of-end system goal.  Is it in scope for the protocol?



> Several organizations have attempted to develop such a system but have

> struggled to overcome the collective burden of needing to independently

> research which constructions from academic literature best satisfy their needs,

> fully understanding each construction’s security guarantees, and maintaining

> their own implementation in production.



Consider if this text is needed.  It doesn’t seem to specify or scope what the WG will do.



> The primary goal of this working

> group is to develop a standard for authenticating information about artifacts in

> an end-to-end encrypted system for human-to-human(s) communication with

> the above properties.



-- Editorial.  s/The primary goal of this working group/The KEYTRANS working group/



-- I see some symmetry in this charter’s construction with how the MLS’s charter was written (https://datatracker.ietf.org/wg/mls/about/) in that it lists properties of the desired protocol and what is not in scope while providing ample flexibility.  Not sure if that is a coincidence.  The desired properties listed are a good start.  However, this text would benefit from clearer statements/requirement on who are the parties and what each would get from this proposed protocol (just like the MLS charter did).



> This allows shared validation, and allows applications to

> share code.



Could this text be clearer on what is means to “share validation”?

> It is not a goal of this working group to develop mechanisms for authenticating

> relationships between artifacts in an end-to-end encrypted system and external

> systems, only that certain data belongs to a given artifact. For example, we

> would not specify ways to verify that an account controls a phone number or

> email address, or belongs to a specific legal person.



I am not sure what it means to “authenticate relationships” or “belongs to a given artifact”.  Is it as simple an identifier can have a collection of other properties associated with it?



> It is also not a goal of this working group to enable interoperability between

> end-to-end encrypted services. Full interoperability of an application would

> require alignment at many different layers beyond security. The focus of this

> work is to develop an authentication mechanism that different applications can

> adapt to their own needs.



“[D]evelop an authentication mechanism that different applications adapt” seems too generic.  Up to this point in the text there is a “protocol”, “authentication scheme”, and now and an “authentication mechanism”.  Recommend streamlining or removing this last sentence.  The first two sentence of this paragraph seem clear to me that this work is not about ensuring generable interoperability.



> Further, it is not a goal of this working group to develop an end-to-end

> encryption protocol for user messages. Rather, the authentication mechanism

> developed by this group will be able to be integrated into other end-to-end

> encryption protocols. The working group will publish a document describing an

> integration with MLS, and may adopt additional documents in the future

> describing the integration of KT with other encryption protocols (where the

> exact security guarantees provided will depend on the underlying encryption).



This is the first time “KT” is mentioned in the document (editorial aside, expand on first use).  Should it be used earlier in the text?  At least from the BoF and the analog to certificate transparency, the current framing of the text seems to be removed from the “key” (it is about artifacts) and the “transparency” properties to deliver are not clearly spelled out.



> The intent of this working group is to follow the pattern of TLS 1.3 and MLS,

> with specification, implementation, and verification proceeding in parallel.



Please be clearer on what this patterning of other WGs means if it is intended to be binding.



-- “Specification”, not sure what this means.



-- “Implementation”, does this mean that there needs to be a number of interoperable implementations before this specification would be submitted to IESG for publication?



-- “Verification”, does this mean that independent, peer-review, formal verification of the protocol needs to occur before being submitted to the IESG for publication?



Are there any WGs with whom coordination needs to be done?  MLS? MIMI?

> Goals and Milestones:

>            Oct 23 - Initial working group document adopted for transparent data

> authentication mechanism.



Editorial.  The above text doesn’t mention “transparent data authentication”.  Consider if this notion of transparency needs to be added in the charter text.



>            Jan 24 - Initial working group document adopted describing MLS

> integration.

>            Oct 24 - Submit both documents to IESG as Proposed Standard.



Consider given delivery a bit more time perhaps into mid-2025.



Consider if adding any supporting documents (e.g., architecture or use case document(s)) would be valuable.  As written, they would not be in scope for the WG.


==[ snip ]==

Regards,
Roman

From: Keytrans <[e-mail]> On Behalf Of Brendan McMillion
Sent: Wednesday, April 5, 2023 4:00 PM
To: [e-mail]
Subject: [Keytrans] Draft Charter

Hello keytrans@

After the successful BoF, the next thing we need to do is agree on a charter for a working group. >From RFC 2418, a working group charter "specifies the direction or objectives of the working group and describes the approach that will be taken to achieve its goals." This side steps some of the technical discussions we were getting into a bit in the BoF, and just says "here's the problem we want to solve, here's how we'll go about that."

I wrote a draft charter here: https://docs.google.com/document/d/12NMFA0P1OYtE6_QoqP3J80tDr0z2-FEm2ZdiWeauAHE/edit?usp=sharing

Please respond on the list if this looks good to you, or you can give feedback either on the list or as comments in the document. Thanks!