Markdown Version | Session Recording

Session Date/Time: 22 Mar 2022 13:30

secdispatch

Summary

The secdispatch session covered four potential work items, with one being cancelled. Discussions focused on identifying existing working groups, evaluating the necessity and scope of proposed work, and assessing community interest. Key outcomes included dispatching an update for syslog cipher suites to the UTA working group, securing AD sponsorship for changes to the IANA SSH registry, and deciding against IETF action for encrypted client hello deployment considerations. A proposal for a trustworthy and transparent digital supply chain architecture was recommended for further community discussion and a potential BoF, with advice to narrow its scope and demonstrate a clear need for IETF interoperability.

Key Discussion Points

• Secdispatch Process: Reviewed the purpose of secdispatch, which is to recommend next steps for new work, with outcomes including direct to an existing WG, new focused WG, AD sponsorship, additional discussion, or no work.
• Agenda Adjustments: The "Key Consistency and Discovery" presentation was withdrawn from the agenda due to the presenter's unavailability.
• Secure Syslog Cipher Suites Update (draft-salloway-syslog-tls-ciphers):
  • The IEC working group referencing secure syslog found that the existing RFC is pinned to TLS 1.2 and deprecated mandatory-to-implement algorithms (TLS_RSA_WITH_AES_128_CBC_SHA).
  • The draft proposes updating the RFC to allow TLS 1.3 and specify TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the new mandatory-to-implement ciphersuite, along with guidance for handling 0-RTT.
  • Ops Area did not have a directly relevant WG but suggested OpsAWG.
  • General consensus in the room leaned towards dispatching to an existing WG, with UTA (Usable Security) being the most favored option as syslog is an application using TLS.
• IANA SSH Protocol Parameters Registry Requirements Update (draft-m-ietf-iana-ssh-reg-update):
  • The draft proposes changing the IANA SSH Protocol Parameters Registry requirement from "IETF Review" to "Expert Review" and establishing an expert reviewers mailing list.
  • The previous working group (CURDLE) is no longer active, making AD Sponsorship the most viable path.
  • The Security Area Directors confirmed they would commit to AD sponsorship for this work.
• Encrypted Client Hello (ECH) Deployment Considerations (draft-andrew-esni-deployment-considerations):
  • The draft aimed to highlight potential impacts of ECH, particularly regarding the loss of SNI visibility for end-users, affecting content filtering and threat detection in environments like schools and enterprises.
  • The authors clarified the intent was not to stop ECH deployment but to ensure thoughtful consideration of its impacts.
  • Many participants argued that these considerations were not new and had been extensively discussed during the development of RFC 8744 (which ECH builds upon) and RFC 8404.
  • Concerns were raised that security relying on inspecting encrypted links is fundamentally flawed, and endpoint-based solutions are preferable for managing devices (e.g., content filtering, malware protection).
  • It was noted that current content filtering based on SNI is already limited by techniques like connection coalescing and malware deliberately lying about SNI.
  • Suggestions included engaging with the TLS WG (to which ECH drafts belong) or contributing to new work on explicit "path signals" for intentional data sharing (e.g., draft-iab-path-signals-collaboration).
  • The consensus was that the IETF had previously considered these issues, and there was no new information or clear IETF action to take on this specific document.
• Architecture for Trustworthy and Transparent Digital Supply Chain (SCITT) (draft-hank-scitt-architecture):
  • The proposal addresses the need for generic, interoperable transparency services for supply chain metadata, beyond just software bills of materials (SBOMs), extending to physical goods (e.g., cold chain for seafood, microchip provenance).
  • It aims to provide a system for creating non-repudiable proofs (cryptographic receipts) that a statement about an artifact was made transparent at a given time, using COSE for signing and WebDIDs for identity.
  • The proposed solution involves an append-only ledger (Merkle tree) that can bundle statements and supports federation of transparency services. Running code in a confidential consortium framework was mentioned.
  • Discussion highlighted the broad scope of the problem statement and the need to narrow it down for IETF work.
  • Key questions for a potential BoF included:
    • Is there a clear need for interoperability among various existing binary transparency systems, or are they sufficiently intra-vendor?
    • Can a minimal viable product (MVP) be defined that is suitable for IETF standardization?
    • Will relevant communities (e.g., developers of existing BT systems, reproducible builds, major platform vendors like Microsoft, Apple, Google, Linux, GitHub) actively participate and commit to implementing a converged IETF standard?
  • Caution was advised against using terms like "web3," "blockchain," or "proof of work" to avoid negative perceptions, instead focusing on "ledger" and technical mechanisms.
  • Emphasis was placed on defining actionable outcomes and accountability mechanisms that result from transparency, not just transparency for its own sake.
  • Proponents were encouraged to meet with interested parties to further refine the scope and community engagement before proposing a formal BoF.

Decisions and Action Items

• Decision: The proposal for "Secure Syslog Cipher Suites Update (draft-salloway-syslog-tls-ciphers)" is tentatively dispatched to the UTA Working Group.
• Decision: The proposal for "IANA SSH Protocol Parameters Registry Requirements Update (draft-m-ietf-iana-ssh-reg-update)" will proceed via AD Sponsorship, with the Security Area Directors committing to find a sponsor.
• Decision: For "Encrypted Client Hello Deployment Considerations (draft-andrew-esni-deployment-considerations)," no action will be taken by the IETF on this document. Proponents could engage with the TLS working group or the IAB's path signals work if they wish to continue discussion.
• Action Item: Proponents of the "Architecture for Trustworthy and Transparent Digital Supply Chain (SCITT)" are encouraged to host a "bar-BoF" to gather further community input, refine the problem statement to a more focused and interoperable scope, and gauge the interest of relevant implementers/stakeholders.

Next Steps

• Secure Syslog Cipher Suites Update: The document authors will engage with the UTA Working Group chairs to initiate adoption or further discussion within that group.
• IANA SSH Protocol Parameters Registry Requirements Update: The Security Area Directors will work to identify an AD sponsor for the document.
• Trustworthy and Transparent Digital Supply Chain (SCITT): The proponents will organize a preliminary discussion (bar-BoF) to scope the work, identify the specific interoperability problems relevant to the IETF, and build community interest. This is a prerequisite for a formal BoF proposal at a future IETF meeting.