Session Date/Time: 23 Feb 2023 18:00

TIGRESS

Summary

This interim meeting focused on discussing updates to the TIGRESS requirements and threat model documents, as well as reviewing one-pagers exploring alternative solution approaches. The primary goal was to address feedback received on the mailing list and in previous meetings, clarify controversial points, and prepare the requirements and threat model documents for a working group adoption call. Significant discussion took place on the scope and wording of several requirements, leading to decisions to refine or remove some. The one-pagers were presented as thought experiments, with WebDAV emerging as a promising base for future protocol development.

Key Discussion Points

Introduction: The meeting began with a welcome from the chair, a reminder of the Note Well, and an outline of the agenda focusing on draft updates and clarifying mailing list discussions.
Overall Work Update:
- Authors provided an overview of work since IETF 115, primarily addressing feedback on the requirements and threat model documents.
- One-pagers on alternate suggested approaches (WebDAV, Signal, GSS-API) were created as thought experiments to gauge how existing or alternative solutions might meet TIGRESS requirements.
Requirements Document Update:
- The requirements document was updated to be more generic, removing user interface (UI) related aspects and adding an example diagram for context.
- Discussion on Specific Requirements:
  - Cross-platform support: Questioned how this requirement could not be met, and if a stronger version regarding specific hardware requirements (e.g., TPM, TE, SE) should be considered. It was suggested to open an issue to discuss core hardware/feature requirements for support.
  - Single-use credential transfer: Clarified that the working group's goal is to define a protocol for one-device-to-another device transfer, not one-to-many. The protocol should accommodate single-use tokens but not necessarily enforce this at the intermediary level (friendly fraud). Concern was raised about imposing enforcement on a relay server. A sense of those present indicated that this requirement, particularly around intermediary enforcement, could be removed for simplicity and considered as a future extension, focusing on the core one-to-one transfer first.
  - Privacy advancement: This requirement was broken into three statements: preventing correlation of users/exchanges, ensuring the integrity server is not an arbiter of identity, and collecting user identification. It was discussed that the protocol should prevent information transmission that allows correlation, rather than imposing a "no collection" requirement on participants. The user identification aspect could be removed if the first two objectives are met.
  - Standard trust (between devices, intermediary server): Questions were raised about the necessity, enforceability, and meaning of "in good standing." It was suggested that the anti-abuse concerns underlying this requirement could be moved to the threat model document rather than being a core requirement. This requirement was agreed to be removed from the requirements document.
  - Multiple round trips: The requirement for quick and efficient communication via multiple round trips was discussed, specifically aiming to avoid polling for battery and network reasons. It was suggested that this could be framed as a "consideration" rather than a hard requirement, and explicitly mention desired mechanisms like notifications or webhooks.
  - Invitation: The requirement for anticipating some kind of invitation/preview for the user to understand what they are about to accept (e.g., self-contained URL/file, deep-linkable) was discussed. Trade-offs and the involvement of UI/UX aspects led to a suggestion that this could also be moved to a "considerations" section.
  - Provisioning Partner: It was generally agreed that keeping the concept of a "provisioning partner" as contextual information in the document is helpful, even if it's not a direct requirement.
Threat Model Document Update:
- The threat model, initially based on a sample implementation, was generalized to cover the overall protocol.
- Discussion on Specific Threats:
  - Threats to a pure sender-to-receiver protocol were outlined with initial likelihood and impact assessments.
  - Discussion arose on whether mitigations listed in the threat model become protocol requirements, or if some are out of scope (e.g., UX problems, device anti-abuse). It was suggested to add a column indicating whether a mitigation is "in protocol" or not.
  - Mitigations such as credential replication and second-factor authentication for provisioning flow were mentioned.
  - Threats related to the intermediary server, such as separate transmission of encryption key and unguessable location, were discussed in terms of user experience and protocol responsibility. It was clarified that the protocol does not necessarily have to enforce such separation but should consider it.
Review of One-Pagers (Alternative Solutions):
- The one-pagers (WebDAV, Signal, GSS-API) were presented as "thought experiments" to understand potential solutions.
- WebDAV: Was seen as a strong candidate, meeting many requirements, and offering a good base for extension (e.g., push notifications, Open Graph for previews). A sense of those present indicated it is a promising approach to explore further.
- Signal: Was deemed less directly applicable as a core transfer protocol because it often implies user accounts and is primarily a messaging system, suitable for the initial URL but not the full back-and-forth transfer.
- GSS-API: Was generally considered not relevant to the core transfer protocol itself, as it's more about credential management within an existing secure context.

Decisions and Action Items

Decisions:

The requirement for "Standard trust" (between devices and intermediary server) will be removed from the requirements document, with underlying anti-abuse concerns to be addressed in the threat model.
The requirement concerning "Single-use credential transfer" (and its previous framing as limiting to one-to-one) will be removed as a hard core protocol requirement, with the understanding that the protocol focuses on one-to-one transfer but can accommodate various credential types. Future extensions might address one-to-many.
For "Privacy advancement," the objective about "user identification not being collected" can be removed if the protocol design ensures the first two objectives (preventing correlation, server not arbiter of identity) are met.
WebDAV is identified as a promising base for further exploration as a potential protocol solution, after the requirements and threat model are solidified.

Action Items:

Authors: Open an issue to discuss core hardware requirements or features related to "cross-platform support."
Authors: Revisit the requirements for "Multiple round trips" and "Invitation," considering reframing them as "considerations" rather than hard requirements in a dedicated section.
Authors: Add a fifth column to the threat model draft to explicitly indicate whether each mitigation is to be addressed "by the protocol" or by other means (e.g., UX, device anti-abuse).
Authors: Address all feedback from this meeting in the requirements and threat model drafts.
Chairs: Initiate a working group adoption call for the updated requirements and threat model documents on the mailing list, after the authors have incorporated the feedback from this meeting.

Next Steps

Authors will revise the requirements and threat model documents based on the feedback received.
The chairs will issue a Working Group Last Call for adoption of the requirements and threat model documents to the mailing list.
Once requirements and threat model are adopted, the working group will further explore WebDAV as a potential base for the protocol specification, considering necessary extensions to meet all TIGRESS requirements.