The Internet Engineering Task Force (IETF) is holding a hackathon to encourage developers and subject matter experts to discuss, collaborate, and develop utilities, ideas, sample code, and solutions that show practical implementations of IETF standards.
When: 14-15 November 2026 (Saturday - Sunday)
Where: Hilton San Francisco Union Square
Room: TBD
Sign up for the Hackathon
View the list of registered:
Keep up to date by subscribing to the IETF Hackathon email list.
The IETF Hackathon is free to attend and is open to everyone. It is a collaborative event, not a competition. Any competition is friendly and in the spirit of advancing the pace and relevance of new and evolving internet standards.
¶ Agenda
Subject to Change
Hackathon (all times are in PST/UTC-8)
¶ Saturday, 14 November
- 09:30 : Room open for setup by project champions
- 10:00 : Room open for all - pastries and coffee provided
- 10:30 : Hackathon kickoff
- 10:45 : Form teams, see Team Schedule
- 12:30 : Lunch provided
- 15:30 : Afternoon break - snacks provided
- 18:30 : Dinner provided
- 20:30 : Room closes
¶ Sunday, 15 November
- 09:30 : Room opens - pastries and coffee provided
- 12:30 : Lunch provided
- 13:30 : Hacking stops, prepare brief presentation of project
- 14:00 : Project results presentations
- 16:00 : Hackathon ends
- 17:00 : Tear down complete
Related activities before and after the Hackathon weekend
¶ Hackdemo Happy Hour
- Share your Hackathon project with the IETF community
- Monday, 16 November, Time: 19:00 - 20:00, Room: TBD
- View the schedule or reserve space for your team/project
- Reservations for space must be made by 13:00, Monday 16 November
¶ Shared Workspace
- Space for groups to gather and collaborate on running code
- Monday - Friday, 16-20 November, Room: TBD
- View the schedule or reserve space for your team/project
NOTE: You will need an IETF Datatracker account to login to the Hackathon Meetecho sessions.
When you register for the IETF Hackathon, you are sent a separate email to create an IETF Datatracker account if you don't already have one.
If you already have an IETF Datatracker account, please ensure that the email address with which you registered is associated with your Datatracker account.
If you received the email but the link to create an account has expired, please see the instructions below:
- Go to https://datatracker.ietf.org/accounts/create/
- Select "New Account" from the User menu at the top
- Enter the email address that you registered with for the Hackathon
- Follow the instructions in the email you receive
¶ Presentation and Meeting Materials
- You can share the code you're working on through the IETF Hackathon GitHub, or via the links provided in the project descriptions below.
- Request to be added to IETF GitHub organization by sending your GitHub ID to (hackathon-chairs@ietf.org).
- Hackathon project result presentations should be uploaded to Datatracker under the specific session Hackathon Results Presentations at 14:00-16:00.
- To upload your presentation, you must have a Datatracker account and be logged in.
- The Hackathon Results presentations from Sunday, 14:00-16:00, are available on Datatracker:
¶ Participant Preparation and Prerequisites
¶ Project Teams and Champions
- Champions are the leads for individual projects in the Hackathon
- Champions are individuals familiar with a given technology who volunteer to help get others get up and running with that technology
- Before the Hackathon, champions should:
- Add information about your project to the list of Projects included in Hackathon
- Recruit participants from associated working groups, open source projects, etc. Announcing your projects via an email to (hackathon@ietf.org) can be helpful as well.
- Specify when and how the project team will meet on the Team Schedule
- At the Hackathon, champions should:
- Make themselves available to answer questions and help others
- Hack on things themselves in their copious free time
- Additional projects are welcome at any time. For any questions, contact the chairs at (hackathon-chairs@ietf.org)
¶ Choosing a Project
- Champions post and lead projects
- Details on each project and links to additional information for each project are in the list of Projects included in Hackathon
- How and when teams meet during the week is up to them and can be found in the Team Schedule.
- Familiarity with technology area(s) in which you plan to participate will certainly help
- It is perfectly fine, even encouraged, to work on multiple projects
¶ Lost & Found
- Participants looking for a team and champions wanting help on their projects are encouraged to visit the Lost & Found.
¶ Development Environment
- Bring a laptop on which you are comfortable developing software
- Some projects may require installing additional software or make use of VMs or containers
- Installing and becoming familiar with !VirtualBox, Vagrant, Docker or something similar may be helpful
- Specific coding languages are called out by some projects (e.g. Python, Go, Java, C++), but this is heavily dependent on the project(s) you choose
¶ Sharing Code
- Git/GitHub is commonly used for open source projects. Familiarizing yourself with it is recommended.
- An online tutorial is available here: Git Tutorial
- The IETF Hackathon GitHub organisation is used by some of the Hackathon projects to host their repositories.
- If you would like to have your project/code hosted here, send your GitHub ID and the name of your project via email to (hackathon-chairs@ietf.org)
¶ Project Presentations
- All teams have the opportunity to present what they did at the end of the Hackathon.
- Hackathon project result presentations should be uploaded to Datatracker under the specific session Hackathon Results Presentations at 14:00-16:00.
- To upload your presentation, you must have a Datatracker account and be logged in.
- DO NOT WAIT until just before the start of the Hackathon project presentations to upload your presentation, as it may be lost in the chaos.
¶ Network
Access to the IETF network
The NOC team has an ongoing experiment that allows you to join the IETF network remotely as well as at an IETF meeting venue.
Requests for networking capabilities beyond wireless access to the IETF network (e.g., wired ports, L2 access, prefix delegation) can be sent to support@ietf.org.
All requests are addressed on a best effort basis. Advance notice is appreciated and improves the odds of your request being fulfilled.
¶ Webex sessions for teams
Champions can request a Webex account they can use to schedule meetings for their team. These are similar to the Webex accounts allocated to working group chairs to be used for virtual interim meetings. An account can be requested by a team champion at any time. Accounts will remain active and available for the duration of the IETF meeting. Request your account HERE. In the request form, you can use your project name where it asks for "Working Group Name" ("Hackathon Project Name").
¶ Ongoing Communication
In addition to registering for the Hackathon and subscribing to the Hackathon list. It is recommended to monitor both the Hackathon wiki and the list as the Hackathon approaches, determine which project(s) are of interest to you, and reach out to the champions of those projects to determine how best to be involved and coordinate with the rest of the team working on each project.
Champions are welcome and encouraged to list times and mechanisms for collaborating with their team in the Team Schedule. Participants can use this page to determine how and when to reach other team members.
The Hackathon kickoff and the project results presentations can be joined via Meetecho. The Hackathon Zulip stream may be used for general and project specific communication.
¶ IPR and Code Contribution Guideline
All Hackathon participants are free to work on any code. The rules regarding that code are what each open source project and each participant's organization says they are. The code itself is not an IETF Contribution. However, discussions, presentations, demos, etc., during the Hackathon are IETF Contributions (similar to Contributions made in working group meetings). Thus, the usual IETF policies apply to these Contributions, including copyright, license, and IPR disclosure rules.
¶ Projects Included in Hackathon
Note, all projects are open to everyone. However, some champions have identified their projects as being particularly good for those who are new to the IETF or new to the Hackathon. These projects are marked with a star, i.e. *. If you are championing a project that is great for newcomers, please add a * at the end of your project name.
For inspiration and examples of previous Hackathon projects see the previous Hackathon page.
¶ RESTful Provisioning Protocol (RPP)
-
Champions
Maarten Wullink maarten.wullink@sidn.nl
Pawel Kowalik pawel.kowalik@denic.de -
Project Info
The RPP working group is focused on designing a new RESTful protocol for registering objects in a shared registry, e.g. xxTLD registries. This will result in a series of specifications known collectively as the RESTful Provisioning Protocol (RPP). -
Hackathon Plan
- Discuss current drafts
- Validate current and future RPP work
- Develop running code based on latest version of drafts
- Other interesting ideas
-
Related documents
¶ Identifier Locator Network Protocol (ILNP)
-
Saleem Bhatti saleem@st-andrews.ac.uk
-
Rodney Grimes rgrimes@freebsd.org
-
Alistair Woodman awoodman@netdef.org
-
Ryo Yanagida ry6@st-andrews.ac.uk (remote)
-
Project Info
- https://ilnp.cs.st-andrews.ac.uk
- RFCs 6740(E) - 6748(E)
- draft-bhatti-ilnp-tcp-udp-checksums
- draft-bhatti-ilnp-textual-representations
- draft-bhatti-ilnp-preference
- draft-bhatti-ilnp-ip6-apps
- draft-bhatti-ilnp-nonce
- The basic approach is to deprecate the concept of an IP Address and replace it with addressing using separate Locator and Identifier values, a pairing of which forms an Identifier-Locator Vector (ILV). Our ongoing research is based on an implementation of ILNP on IPv6 using FreeBSD.
¶ Low-Power Wireless IPv6 Networking with Thread *
-
Champion
Stuart Cheshire <cheshire@apple.com> -
Thread Overview
Thread is a specification for how to carry IPv6 datagrams over a self-configuring mesh of low-power IEEE 802.15.4 wireless links. Stuart Cheshire gave a brief presentation about Thread at the IETF 119 IAB Open meeting in Brisbane. The Thread specification is developed and published by the Thread Group. There are several independent implementations of Thread, the main one being the OpenThread open source project. This Hackathon event is open to all — Thread Group membership is not required, though of course Thread Group members are also welcome to participate.
-
Participants and Project Info
- To avoid taking up too much space on the main Hackathon page, Thread participants and projects are listed separately on the Thread Projects page.
¶ Low-Latency, Low-Loss, Scalable Throughput (L4S) and Accurate ECN Interop
- Champions
Greg White (g.white@cablelabs.com) - Project Info
L4S and AccECN enable applications to receive fine-grained congestion feedback from the network that allows them to achieve full link utilization, ultra-low latency, ultra-low latency variation, and near-zero packet loss.
This Interop Event will bring together different congestion control implementations and different network implementations of L4S, TCP Accurate ECN, QUIC AckECN, WebRTC, etc. to test RFC/draft compliance, interoperability, and performance in various conditions. - Related RFCs
RFC9330
RFC9331
RFC9332
RFC9768
RFC8888
¶ 802.11 MAC Performance as a Function of Active IP Devices
-
Champion
- Bob McMahon, Umber Networks, bob.mcmahon@umbernetworks.com
-
Project Info
- This project will measure 802.11 MAC performance as a function of the number of active IP devices and offered load.
- We will use a controlled 802.11 test environment in which the number of actively contending devices can be varied while independently observing both MAC behavior and application/transport performance.
- The experimental system includes a controlled MAC load generator with up to 45 Wi-Fi clients, a programmable 2x2 MIMO RF test rig, passive Umber Sonde monitors, a conventional Wi-Fi AP, an Umber UAX-8 system, and synchronized iperf2 measurement endpoints.
- Initial measurements will examine aggregation, contention, retries, useful airtime, throughput, latency, and responsiveness as the number of active devices increases.
- We will correlate endpoint measurements with independent observations of activity on the air and repeat experiments under controlled RF conditions.
- Once the MAC behavior is characterized, we will explore the effects on congestion control, ECN/L4S, and user-perceived delay.
- Additional experiments will compare conventional distributed Wi-Fi operation with centralized coordination using the Umber architecture under the same RF conditions, active-device population, and offered load.
- Participants are encouraged to suggest experiments, examine the measurements, bring congestion-control implementations, and use their own devices as measurement endpoints.
- MAC rig: https://www.umbernetworks.com/mac-rig-reference.html
- Fi-Wi problem statement: https://www.umbernetworks.com/ietf-fiwi-problem-statement.html
- iperf2 Android client: Google Play
¶ Independent time anchoring
-
Champions
- Jonna Fassbender, Umarise, j.fassbender@umarise.com (remote)
-
Project Info
- This project is about proving that a given digest existed no later than a given point in time, and verifying that claim offline, without contacting the party that produced it and without trusting a block explorer.
- Draft: draft-fassbender-scitt-time-anchor
- What we are looking for is implementations written from the document alone. Test vectors are in Appendix D; the negative ones are in D.6. If your implementation accepts the positive vectors and rejects the negative ones, the specification did its job. If you had to guess somewhere, or two readings of a step were both defensible, that is the result we most want to hear.
- Note that a proof is only complete once the anchoring transaction is confirmed, so a live run spans at least one block interval. The vectors let you test verification without waiting.
- Any language. A Bitcoin full node is useful but not required; a validated header set is enough.
¶ Addressing Multi-Agent Delegation: TTTPS & AUDIT Open Testbed *
-
Champions
- Heime Jorgen, Kenosian, heime.jorgen@proton.me
-
Project Info
- Objective: Demonstrating Hardware Temporal Attestation (TTTPS 180-octet PoT Core + AWS Nitro PTP) and Fail-Closed Replay Ledger (Amazon MemoryDB for Redis) for high-speed, asynchronous multi-agent delegation.
- AUDIT BoF Support: Providing a "Running Code" Open Conformance Testbed and K-Lean Formal Verification API in support of the AUDIT (Agent Use of Delegation and Interaction Traceability) BoF.
- Formal Verification (K-Lean Engine):
- Live Conformance API:
https://kpp.kenosian.com/api/verify - Proof Vault & UI:
https://kpp.kenosian.com/k-lean.html|https://kpp.kenosian.com/kenosian-vault - Evaluates 5 Formal Invariant Fixtures:
BoundedParse,InvalidIngressNoMutation,ValidIngressMayCommit,AtomicReplayAtMostOneCommit, andDropHasNoDisposition.
- Live Conformance API:
- Specifications:
- Repositories:
- OpenTTT Core Engine: https://github.com/Helm-Protocol/OpenTTT
- OpenTTT MCP SDK:
@helm-protocol/ttt-mcp
- Looking for: Participants interested in AI agent security, RATS CMW / SCITT receipt logging, or testing synthetic time-skew and replay attacks against O(1) admission gates.
¶ OpenNHP: Network-infrastructure Hiding Protocol (NHP) *
-
Champions
Benfeng Chen
benfeng@gmail.com
support@opennhp.org(Newcomers, security researchers, and AI-assisted testers are welcome — remote participation supported.)
-
Project Info
OpenNHP is an open-source implementation of the Network-infrastructure Hiding Protocol (NHP), a Zero Trust protocol that provides authenticate-before-connect semantics: protected resources stay invisible to the network until a client proves its identity cryptographically.
An AI vulnerability storm is coming. AI systems can now find new vulnerabilities, write exploits, and scan the entire Internet faster than ever. Traditional security (patching, signatures, and detection-and-response) is too slow to keep up: an exposed service can be found and attacked within minutes of a new flaw being discovered. We believe the most effective defense is not to out-race AI attackers but to hide from them. If an attacker cannot see a service, it cannot scan, fingerprint, or exploit it, no matter how capable the attacker is.
At IETF 126, independent testers, including an autonomous AI attacker, found no way to reach protected services without authentication. Passive reconnaissance did show that DNS and Certificate Transparency logs can reveal parts of the deployment topology. For IETF 127 we have hardened the public demo and invite participants, human and AI, to try again.
-
What's new since IETF 126:
server.opennhp.orgis now fully invisible — no HTTPS surface; it only answers valid NHP knocksac.opennhp.orgenforces access with eBPF/XDP, dropping unauthorized packets at the network driver before the Linux TCP/IP stack- New login-portal integration demo at
demo.opennhp.org - JavaScript SDK agent and NHP-Relay (HTTP-to-NHP translation) for browser-based clients
-
Challenge objectives include:
- Discovering or accessing protected services without authentication
- Pointing AI and autonomous agents at NHP-protected infrastructure to see how far they get
- Passive reconnaissance: CT log and DNS enumeration, metadata correlation
- Active scanning of hidden ports, IP addresses, and domain names
- Bypassing authentication or authorization, including replay and knock-forgery attempts
- Testing DDoS and pre-authentication attack resistance of the eBPF/XDP data path
- Reviewing the protocol design against draft-opennhp-ztcpp-nhp
- Interoperability and performance testing
-
Success criteria:
- If you can discover or reach a protected resource without authenticating, we want to understand and fix the weakness.
- If you can't, your results add independent evidence that hiding is a practical defense against AI-driven attacks.
- Either way, we will publicly credit participants who share findings.
-
Links:
- Call for Participation: https://opennhp.org/blog/ietf-127-hackathon-call-for-participation/
- Website: https://opennhp.org/
- Source Code: https://github.com/OpenNHP/opennhp
- Live Demo: https://opennhp.org/demo/
- Internet-Draft: https://datatracker.ietf.org/doc/html/draft-opennhp-ztcpp-nhp
- IETF 126 Results: https://opennhp.org/blog/ietf-126-hackathon-results/
¶ AER-1: Verifiable AI Agent Execution Receipts *
- Champions
-
rambo (AI ops, Zambo) rambo-ops@agentmail.to (remote)
-
Project Info
-
AER-1 defines a verifiable receipt for AI agent executions: a tamper-evident record of what ran, what it touched, and what came out, with canonical JSON serialization and a conformance test-vector suite.
- What we are looking for is implementations written from the document alone, in new languages. Test vectors ship with the kit; if your implementation accepts the positive vectors and rejects the negative ones, the specification did its job. If you had to guess somewhere, that is the result we most want to hear.
-
Any language. Independent implementations already exist in TypeScript, Python, Node.js, Java, Perl, Rust, Go, C#, and Swift; open lanes include Ruby, PHP, Lua, Elixir, Zig, Dart, Scala, and Haskell.
-
Kit (conformance runner + vectors): https://gitlab.com/rambozambodotdev/zambo
-
Live demo, no signup: https://rambozambodotdev.gitlab.io/aer1-hub/try/
-
¶ Validate YANG-Push to Message Broker End-To-End Data Processing Chain
-
Champion(s)
Thomas Graf (thomas.graf @ swisscom.com)
Leonardo Rodoni (leonardo.rodoni @ swisscom.com)
Maxence Younsi (maxence.younsi4 @ swisscom.com)
Ahmed Elhassany (ahmed.elhassany @ swisscom.com)
Benoit Claise (benoit @ everything-ops.net)
Paolo Lucente (paolo @ pmacct.net)
Vivekananda Boudia (vivekananda.boudia @ insa-lyon.fr)
Pierre Francois (pierre.francois @ insa-lyon.fr)
Rob Wilton (rwilton @ cisco.com)
Daniel Voyer (davoyer @ cisco.com)
Scott Huang (scohuang @ cisco.com)
Muthumayan Madhayyan (muthu @ cisco.com)
Deepya Mandadi (dmandadi @ blueplanet.com)
Jérémie Leska (jeremie.leska @ 6wind.com)
Irfan Mohammad (irfan @ arrcus.com)
Per Andersson (per.ietf @ ionio.se)
Mohamed Kheir (mkheir @ singlestore.com) -
Draft Specifications Message Broker
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-message-broker-telemetry-message
https://datatracker.ietf.org/doc/html/draft-netana-netmod-yang-anydata-validation -
Draft Specifications YANG-Push
https://datatracker.ietf.org/doc/html/rfc8639
https://datatracker.ietf.org/doc/html/rfc8641
https://datatracker.ietf.org/doc/html/rfc9196
https://datatracker.ietf.org/doc/html/rfc10035
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yp-transport-capabilities -
Project Info
https://www.network-analytics.org/yp/, validate and verify -
6 YANG-Push Publishers
-
3 YANG-Push Receivers
-
3 YANG-Push Network Telemetry Message
-
2 YANG Message Broker Producer
-
1 Schema Registry
-
3 YANG Message Broker Consumers
implementation in the area of YANG data schema validation and obtaining latest YANG-Push subscription state. Subscribe to YANG data on YANG-Publisher, obtain and register all YANG modules necessary to build YANG schema tree, register YANG schemas to Schema Registry and verify YANG notifications against scheme trees and produce and consume from Message Broker.
- Repositories
https://github.com/network-analytics/ietf-network-analytics-document-status/tree/main/127/Hackathon
https://github.com/network-analytics/yang-kafka-integration
https://github.com/network-analytics/NetCalyx/releases/tag/v0.3.0
https://github.com/NetGauze/NetGauze/releases/tag/v0.13.0
https://github.com/pmacct/pmacct
https://github.com/CESNET/libyang/releases/tag/v5.4.9
¶ SW103K Layer 2 Compression and Decompression Protocol Interop
-
Champions
Katerega Micheal (chief3@chazahgroup.org) -
Project Info
SW103K is a Layer 2 compression and decompression protocol designed to enable efficient data representation for transmission and storage while preserving the ability to reconstruct the original data when required. The protocol supports diverse applications and use cases without being limited to a specific industry or deployment scenario.
This Interop Event will bring together SW103K implementations and test environments to evaluate interoperability, compression and decompression correctness, data integrity, and performance under different data and operating conditions. Initial testing will focus on two use cases: bandwidth reduction during data transmission and storage reduction through compressed-data persistence, with decompression and restoration performed only when explicitly requested. Testing will measure compression efficiency, data size reduction, throughput, processing overhead, and accurate reconstruction of the original data.
¶ EarlyAttestationBleed, EarlyAttestationTschüss (EAT) and co: CVE-2026-100833 of CVSS 9.6, CVE-2026-108265 of CVSS 9.1, CVE-2026-108266 of CVSS 9.1, CVE-2026-108267 of CVSS 9.1, CVE-2026-108268 of CVSS 9.1, CVE-2026-108269 of CVSS 9.1, CVE-2026-100835 of CVSS 9.1, CVE-2026-92701 of CVSS 9.1, CVE-2026-92702 of CVSS 9.1, CVE-2026-33697 of CVSS 7.5, and more to come
-
Champions
- Muhammad Usama Sardar (muhammad_usama.sardar at tu-dresden.de)
- Viacheslav Dubeyko
- Jean-Marie Jacquet
- Songbo Bu
- (Please feel free to add your name here)
-
Potential collaboration with other projects/champions
- TBA
-
Draft vulnerable to CVEs
- Early attestation
Summarized in draft-intra-handshake-fail
-
Project Motivation
- https://www.theregister.com/security/2026/07/04/confidential-computings-trust-mechanism-is-broken-the-fix-may-not-exist/5266056
- https://www.scworld.com/brief/confidential-computings-remote-attestation-protocol-may-have-fundamental-flaw
- https://blogs.groupware.org.uk/01-Quantum-Inc/the-handshake-that-cant-keep-its-promise-why-confidential-computings-flaw-changes-the-data-sovereignty-conversation/
- https://thenextgentechinsider.com/pulse/critical-flaw-discovered-in-confidential-computing-attestation-protocols
- https://www.securitylab.ru/news/574545.php
- Russian https://www.securitylab.ru/news/574545.php
- German https://www.blogspan.net/confidential-computing-attestierung-relay-luecke/
- https://dailysecurityreview.com/resources/cve-2026-33697-attested-tls-relay-flaw-hits-whatsapp-cocos-ai/
- Chinese https://finance.sina.cn/tech/2026-07-04/detail-inifscxt9953361.d.html
- https://data4biz.com/articles/una-falla-rompe-la-fiducia-del-confidential-computing
- Japanese https://blackhatnews.tokyo/archives/119915
- https://www.dugganusa.com/post/confidential-computing-s-whole-pitch-is-trust-the-proof-not-the-cloud-two-years-of-formal-verifi
- https://post.smzdm.com/p/a82ol990/
- Russian https://www.itsec.ru/news/issledovateli-nashli-kriticheskuyu-uyazvimost-v-attested-tls
- Chinese https://blog.csdn.net/weixin_42376192/category_13096766.html
- https://daily.dev/posts/bad-epoll-hits-99-reliability-sharepoint-rce-under-active-exploitation-zgp0yt8lh
- https://meterpreter.org/attested-tls-vulnerability-cve-2026-33697/
- https://osintsights.com/confidential-computing-flaws-expose-trust-risks
- https://www.boerse-express.com/news/articles/digitale-souveraenitaet-vergabebeschleunigungsgesetz-staerkt-europaeische-cloud-ab-juli-924836
- Turkish: https://hardwaremania.com/haber/arastirma-attested-tls-confidential-computing-icin-zayif-kaliyor/
- https://akber.com/sovereignty-in-the-cloud-is-an-illusion/
- https://www.itsec.ru/news/issledovateli-nashli-kriticheskuyu-uyazvimost-v-attested-tls
- German https://www.ad-hoc-news.de/wissenschaft/digitale-souveraenitaet-bundesregierung-beschliesst-34-punkte-paket/69692503
-
Implementations vulnerable to CVEs
- Meta’s Private Processing for WhatsApp
- Edgeless Systems Contrast -
Project Background
Code under Apache-2.0 License: https://github.com/muhammad-usama-sardar/intra-handshake.fail
Paper: https://www.researchgate.net/publication/408219182_Intra-handshakefail_CVE-2026-33697_High-severity_CVE_in_Attested_TLS
Paper: https://www.researchgate.net/publication/414529199_EarlyAttestationBleed_Three_Critical-severity_Vulnerabilities_of_CVSS_90_in_Confidential_Computing -
Project Info
- 3 fundamental ways to combine attestation in TLS:
- Pre-handshake attestation
- Intra-handshake attestation
- Post-handshake attestation
- Internet draft
- Sec. 4 in this paper
- Complicated Hybrids (Intra-handshake attestation + Post-handshake attestation)
- 3 fundamental ways to combine attestation in TLS:
-
Hackathon plan
- Discuss the nits of relay attacks
- Discuss possible solutions
- Discuss open issues
- What is the "long-term identity" of the CC workload? How is "long-term identity" assigned to the CC workload? Which entity supplies this "long-term identity"? How is that Identity Supplier trusted?
- How is CA-certified Long-Term Key (LTK) injected in the Confidential Computing workload in the first place?
- Formal evaluation of hybrid proposals in SEAT: which security property is provided by the hybrid (intra+post) proposals that is not provided only by the simple post-handshake attestation to absorb this complexity
- We aim to seek collaborators (knowledgeable about at least one of the following: TLS, remote attestation, formal methods or confidential computing) who will join us in this project. We also welcome reviewers who can give us feedback on the draft. If you are interested, please contact by email.
- Tool for formal analysis: We currently use ProVerif but other tools are very welcome.
-
Background on Attestation
-
Background on Diversion Attacks
-
Background on Relay Attacks
¶ AI2II: AI-Assisted Protocol Implementation & Interoperability
-
Champions
- Alexander Pelov (IMT Atlantique) — alexander.pelov@imt-atlantique.fr
-
** Supporters **
- Marco Tiloca (RISE) — marco.tiloca@ri.se
- Rikard Höglund (RISE) — rikard.hoglund@ri.se
-
Project Info
Bring an Internet-Draft. Build with AI. Test interoperability!
AI2II (AI-to-Implementation-to-Interop) explores how AI coding agents can accelerate protocol implementation, verification, and interoperability testing.
The goal is pragmatic: produce running code, test it against independent implementations, identify problems, and provide feedback to IETF draft authors.
What can you do?
- Port: Take an existing implementation and its draft, and port it to another language.
- Implement: Start from an Internet-Draft and build a new implementation using AI coding agents.
- Extend & Fix: Add protocol features, discover bugs, and generate regression tests.
- Interop: Test independent implementations against each other and investigate failures.
A framework to get started
We bring an existing open-source multi-agent framework providing separate implementation and verification agents, automated tests, interoperability checks, and structured feedback.
The framework is a starting point, not a prescribed methodology. Bring your own coding agents, models, and workflows. The objective is working implementations, not promoting a particular tool.
Learning from the experience
Alongside the code, we aim to document the approaches used, including tools, models, workflows, successes, failures, and human interventions. These experiences will contribute to a shared AI-Assisted Protocol Engineering Cookbook to help the IETF community learn what works.
Candidate experiments
- OSCORE Multicast Notifications: Port an existing C implementation and test interoperability. ( https://github.com/apelov/coap-multicast-notifications )
- ICMPv6-SEC: Implement experimental QUIC timer adaptation and evaluate it in a high-delay network testbed.
- CORECONF / SCHC: Generate implementations and tests for YANG/CBOR-based management.
- Your own Internet-Draft or implementation!
Expected outcomes: Running code, test vectors, interoperability results, bug fixes, feedback to draft authors, and reusable lessons learned.
Good for newcomers: Yes — examples and guidance will be available.
Repository: (link to be added)
Don’t see anything that interests you? Feel free to add a project to the list, sign up as its champion, and show up to work on it. Note: you must login to the wiki to add content. If you add a new project, we suggest you send an email to (hackathon@ietf.org) to let others know. You may generate interest in your project and find other people who want to contribute to it.
TEMPLATE: Copy/paste and update the following template to add your project to the list:
### Your Project
- **Champions**
name and email
- **Project Info**
project description
To edit the wiki, log in using your IETF Datatracker login credentials. If you don't yet have an IETF Datatracker account, you may get one by going here and requesting a new account.