# Rolling agenda

This is a rolling agenda for discussions around hardware-backed attestation in TLS. Please feel free to add new items and comments to existing items.

* Status update for IETF 120?

# Rolling agenda for Formal Verification meeting
For 28.10
* Discuss first and last para of both properties of RA-TLS paper
* Need for per-session freshness: What exactly can change? Runtime measurements?
* Discuss plan of side-meetings

Backlog:
* Add tradeoffs in table
* Usability/Ease of use
* Complexity of implementation/formal verification
* Plan at IETF 121: Present at [Alldispatch](https://mailarchive.ietf.org/arch/msg/alldispatch/lHB1axTB5ikL4Kv-KVo2YN11rvk/)
* Tradeoffs table
* Attested Secure Channels tree diagram
* Sync on terminology for keys (see slack)
* Channel binder of v7 is not justified. It doesn't improve any security.
* Discuss about new ideas for AsiaCCS
* Motivation for Attestation alongside X.509
* With the channel binder of v6, is there any attack possible without leaking privEK? No
* Discuss the progress so far:
1. **Without leaking privEK**: Attacker can replay evidence but not succeed in establishing the connection. Depending on how much time it takes to verify the evidence, we can probably make a case for DoS attack for "Client as Attester"
2. **With leaking privEK**: Attacker can replay evidence and also succeed in establishing the connection.
3. **With intra-HS protocol and even with leaking privEK**: Attacker cannot replay evidence (since it is signed by privAK) as the additional freshness check at the client side will fail (assuming Server as Attester). Multiple failed connections may also help the client detect that Server's key has been leaked.

**Results for RA-TLS (2-party)**
Property | Without privEK leak | With privEK leak |
| -------- | -------- | -------- |
| Replay protection of Evidence | False | False |
| Server authentication | True | False |

**Results for Fix to RA-TLS (Intra-HS) (2-party)**
Property | Without privEK leak | With privEK leak |
| -------- | -------- | -------- |
| Replay protection of Evidence | True | True |
| Server authentication | True | False |

* Ideas for future work
* [Mutual RA-TLS](https://github.com/muhammad-usama-sardar/attestedTLS/issues/29)
* [Attacks on TLS 1.2](https://github.com/muhammad-usama-sardar/attestedTLS/issues/30)
* OCP presentation review: [Last 2 tasks in this issue](https://github.com/muhammad-usama-sardar/attestedTLS/issues/26)
* I think the (future versions of) draft/presentation really needs to say in clear words a few things:
* What exactly is attestation?
* Why attestation is required in TLS?
* What bad things may happen if attestation is not there in TLS?
* What bad things may happen if attestation is not done in intra-HS way?
* Why is attested TLS better than competing solutions? Bryan Kelly said some folks presented SPDM for network at OCP. [Issue](https://github.com/tls-attestation/draft-tls-attestation/issues/50)
* IETF draft is mainly intended for implementors [Thomas]. We may put this motivation in a webpage and link it in the draft.
* [Issue # 31](https://github.com/yaronf/draft-tls-attestation/issues/31)
* Ionut to make a flow diagram for verification
* Discuss open questions for formal verification
* Fig. 12 in [[Draft](https://www.ietf.org/archive/id/draft-fossati-tls-attestation-04.html#name-cloud-confidential-computin)]: what does it mean to have TLS handshake cover the Verifier also? Isn't it a separate TLS connnection?
* Finalize [flow for CC use case](https://github.com/muhammad-usama-sardar/attestedTLS/blob/main/attestedTlsFlow.md) ([Issue#26](https://github.com/yaronf/draft-tls-attestation/issues/26))
* (keyID) Where do we put the metadata/handle of the TIK, so that the server can reference it when the TIK is held in a realm?
* What are the benefits of varying sizes of target environment? If we only use RA for TIK, do we get any benefits over an HSM?

## Actions

> [name=Thomas Fossati] ask Arto:
> 1. whether he's ok with the proposed solution;
> 2. whether he'd be ok with co-authoring

> [name=Thomas Fossati] re-publish draft-kat without changes. In parallel, decide what to do longer term (e.g., get ASSA ABLOY on board)

> [name=Ionut Mihalcea] prepare a diagram for issue #31 using TLS figure as baseline (for formal verification)

# Meeting notes 18.11.24 (HT,TF,IM,YS,US,YD)
Cases where I-D might help:
- RTM may sample at regular intervals of time. (Not useful if the RoT measures only at boot time, e.g., Arm PSA)
- RoT that allows live update.
Use case: if the state changes frequently enough, reusing static attestation credential is not good.

Imagine there is FW update and pre-handshake attestation. Need SW update event in RoT
Like IMA continuously log all events. (append-only). IMA is pluggable.
Claim freshness vs. Evidence freshness: Time at which each claim in claim set was collected (no trusted clock in CC; At boot-time there are only ticks [no real clock]) vs. signature formation
- impersonation?

### Identity
Identity (stable identifier) = measurement of workload or common name?
For Intel, identity = measurement + raw public key (privEK) that TEE generated
I-D: identity =
- only the verifier can know (supply chain actor)
- common name in the cert
- Verifier owner

# Meeting notes 11.11.24 (HT,IM,MS,US)
We discussed potential next steps today. Our feeling during the IETF week is that the concept of freshness is not well-understood. Our plan is to discuss freshness next week and clarify the concepts around that.

Suggested resources before meeting:

- CCC Attestation SIG discussion on freshness: https://youtu.be/e9LGum03Y00?list=PLmfkUJc39uMhZsNGmpx-qD-uCoQyMglIp&t=345
- CCC Attestation SIG meeting notes https://github.com/muhammad-usama-sardar/attestedTLS/issues/63
- Dionna's point of view on freshness: https://github.com/muhammad-usama-sardar/attestedTLS/issues/64
- Ned's point of view on freshness: see item 4 on https://github.com/muhammad-usama-sardar/attestedTLS/issues/65
- Henk's point of view on freshness vs. recentness: https://github.com/muhammad-usama-sardar/attestedTLS/issues/82
- Initiated discussion at RATS: https://mailarchive.ietf.org/arch/msg/rats/5JGr21UUgx1MsjIG64jVnHTPQNs/

Feel free to add to the list.

# Meeting notes 15.08.24 (YS,CW,US)

* Potential implications on the protocol for TPMs (vs. TEEs) due to slower generation of evidence by TPMs.

* Fix for replay attack on RA-TLS with pre-HS attestation: Other than storing state (i.e., storing the evidence that we mention in the paper), Carsten pointed out a (theoretical?) solution based on trusted and synchronized clocks. Any thoughts on that?
* Relay attack on intra-HS attestation (I-D v6) with the threat model that TLS Identity Key (TIK) of Attester has been leaked. Something we did not discuss and what I was thinking afterwards is that, with this threat model, relay attack should still be possible on RA-TLS (just my thinking; not formalized yet). I am not sure why Table 1 in the Middleware paper says RA-TLS prevents relay attack. Any thoughts?
* Carsten reminded me that there is an overlap for the paper planned for AsiaCCS (vs. the one submitted in Middleware) with regards to the point on proposing a solution for relay attack. While formalization is a key difference between the two works, we will discuss this further after getting the reviews from Middleware.

IMHO, in the next meeting we should really discuss what exactly the threat model is and then agree on properties that we aim for (even if they are informally stated). This would be very helpful for formalization, security consideration section as well as making proper design choices. Perhaps also good to make a decision about post-HS vs. intra-HS soon to avoid extra effort.

# Meeting notes 25/Apr/24

* Round-table introductions
* TODO: Need to confirm the dates for the meetups and send out invite.
* USENIX paper:
* got feedback, send author feedback; waiting for more feedback
* Q: what does "independent failure" mean?
* normally if you lose attestation key, you lose proof that the attestation in the TLS handshake is representative of the peer. Independent failure aims to cover that gap.

* What's the plan until IETF event?
* [Linaro Connect workshop](https://hackmd.io/@A_TVjSksQxWv7wvs1Ghhiw/r1BdwS3xC): what do we want to achieve?
* it seems there'll be at least 7 people in person there
* we need to decide what to do there
* Usama put forward a talk on the formal verif side
* would be nice to have something for all 3 tracks (formal verif, proto, drafting) + use-cases
* Paul would like to discuss his submission to the CNCF conference (topic: using attestation in Cloud-based service meshes)
* Thomas to put together the calendar using the HackMD page
* half day of presentations, half day of working in Working Groups
* We still have to decide on when and if for the Dresden meeting.

* Jimmy and Ondrej from Ericsson have said they'd like to join the community; have been working on an implementation of the draft in Rustls.

* Q: What's the plan for the I-D?
* We need to go through [the issue list in Github](https://github.com/tls-attestation/draft-tls-attestation/issues) and close as many as we can before next cut-off.
* Should focus more on the binder in the next few weeks.
* Q: What's the status of the PoC?
* The [PoC](https://github.com/CCC-Attestation/attested-tls-poc) exists, but is somewhat stale and implements only a sliver of what the draft allows. It's also geared for TPM2.0 and built on top of mbedTLS, but hopefully we'll get some interoperability in the future.
* Q: Are we gated on having interoperable implementations?
* For IETF adoption yes, but not for WG adoption. We'll eventually need to provide some implementations, at the moment we're just focused on having something that works, and on polishing the I-D for adoption.
* Q: What's the status of the I-D? How stable is it? No changes in the draft repo for some time now.
* The draft goes through a boom-and-bust cycle with every IETF event, so contributions are quite irregular in time. At the moment we still have quite a lot of issues still open on the draft, and a few PRs. The background check side of things is more stable than passport model, though some things might need more work (e.g., the binder). Reviews of the current state of the I-D are more than welcome.

# Meeting 05.02.24
* Discuss feedback/questions from [CCC SIG meeting presentation](https://github.com/CCC-Attestation/meetings/blob/main/materials/MuhammadUsamaSardar_Formal_RA-TLS.pdf)
* [Question by Greg](https://github.com/CCC-Attestation/meetings/pull/28#issuecomment-1919109159)
* Discuss with Nikolaus how SCONE manages it. Thomas interested in joining this discussion.
* Question by Ned: Would DICE layering prevent the replay attack? Discuss how DICE layering would be relevant at protocol level?
* TF: no relevant reference to our knowledge,
* Alias in DICE terminology: Leaf cert generated on the fly
* Usama: Unclear whether leaf cert here would be PCK cert or Quote
* Question by Ned: "Evidence generation" on slide 9: does it include "Claims collection" in addition to "Claims reporting"?
* claims reporting (signing) only
* claims collection at boot-time (except for the runtime measurements)

# Meeting 08/01/24

- TLSA paper is due in about a week's time
- Ionut will submit it for Arm review
- Confirmed there's no need for diagrams showing mutual authentication via attestation
- The current design does not allow peers to negotiate or communicate details about the RA scheme, so the peers need to have agreed on it out of band
- This isn't necessarily a problem for the paper, but we need to explain clearly that this is a gap in the design
- As a solution, we could point to our draft, but this brings some problems since the submission should be anonymous
- We could just point to a "stub" link for the draft and say that a proper way of implementing the negotiation is defined there, and the stub will be replaced in the final paper
- Code-wise:
- A very hacky first version of the CCA implementation seems to work, so can be mentioned in the paper
- The rest of the code looks better and will be submitted after the first stages of the paper assessment
- It would be good to have the whole thing cleaned up and ready for publishing, but there's still some time before that
- Attested TLS prototype code
- We should look at it again and fix the existing issues, as it's been slowly rotting
- Issues on the draft repo
- How do we share the PoP for the attested key when we have both PKIX and RA?
- The CertificateVerify message is not extensible, so we can't take the same approach as for the Certificate message
- There are a couple of options:
- We either add another CV message to carry the signature of the attested key on the handshake
- We bundle in the PoP for the attested key in the same CMW that's used to carry the attestation credential
- We chose the latter as it means minimal changes to the actual TLS protocol, but we need to have some formal proof that this would not raise significant issues

**NOTE: Two meeting note sets are missing**

# Meeting 27/11/23

* Went through issues on TLS draft repo and assigned them
* Some meatier discussions focused on the relationship between TLS and KAT drafts
* Outcome:
* We should define the relationship between TLS and attester more thoroughly
* We'll keep the two drafts separate, and hope for other key attestation drafts covering other types of tokens/interactions in the future
* Discussed the requirements for the OpenSSL implementation & paper
* Interested in showing that the implementation is RoT/token format agnostic
* Closer integration with CCA stack would be nice, but not a requirement
* Difficult to decide, as there's no strong requirement to open source the entire thing right now, so the delay on the CCA side is not that problematic

# Meeting 20/10/23

* Discussion on a paper Usama is writing on formal verification, including modelling the CCA remote attestation flows
* Agreed on better wording for the mention of formalisation work for attested TLS
* An updated version of the paper on attestation in TLS is in the works by Carsten, Michael, Usama
* Interested in trying out their TLS stack on an Arm CCA emulator
* TBD what the best avenue for that would be

# Meeting 13/10/23

* Hannes has sent a [message](https://mailarchive.ietf.org/arch/msg/emu/G_s8WRnMIqmpLfnOrS2ptfaVedk/) to the [EMU WG](https://datatracker.ietf.org/wg/emu/about/) -- i.e., folks working on network access assessment (EAP in particular)
* RFC 9334 already mentions network endpoint assessment as a use-case for RA
* We're working on a way to integrate attestation in TLS, so TLS-based EAP can then easily use our work
* Offered to present at IETF 118 if they're interested
* Also some interest from Daniel Migault (who's also worked on [LURK](https://eprint.iacr.org/2020/1366.pdf))
* Enarx:
* Get in touch to see what their interest is based on/if our work is relevant to them
* Passport model
* Heightened interest in the privacy implications of RA (due to [IAB's statement on the risks of attestation](https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/))
* Attestation results could be a natural way of mitigating this
* Bringing verifier closer to attester means the metadata with most privacy concerns can be better controlled by its owner
* All the verifier needs to output is one signed bit saying "yes, trustworthy" or "not trustworthy"
* The format of the attestation results can have significant implications
* If it's an EAR, then we can just do something similar to how we handle attestation evidence
* However, some projects (Veracruz, Enarx) have been using x509 as attestation results; This has some knock-on effects
* There needs to be a CA involved somewhere, using something like the LAMPS or ACME modes of integrating RA
* The exact architecture becomes more complicated, depending on how the attester, verifier, and CA relate to each other and communicate
* Potentially, there could be some privacy-preserving measures between verifier and CA, so CA never knows the full identity of the attester
* Ionut will begin writing up a first-draft version of the Passport Model text
* Open PRs, for all to review:
* Yaron's PR on KAT: https://github.com/thomas-fossati/draft-kat/pull/14
* Ionut's PR on aTLS: https://github.com/yaronf/draft-tls-attestation/pull/25

# Meeting 06/10/23

* TODOs before IETF 118 cut-off?
* TODO: Decide what issues we want to address in the draft
* Editorial changes that are already mentioned in the [Github issues](https://github.com/yaronf/draft-tls-attestation/issues)
* Add information about security concerns as we've been discussing
* Adjust the diagrams around where the trust boundaries are found for client attestation
* We should address the IAB statement on privacy repercussions of RA
* Do our use-cases really have the same privacy implications of things like WEI?
* IoT device on-boarding: TLS client is likely the attester, so the IAB statement might be relevant
* Confidential computing: TLS server is likely the attester, need to see what that implies
* If we look at Privacy-Pass:
* using our proposal between attester and verifier should be fairly straight-forward
* but how could we integrate on the attester-relying party side? could we integrate the PP tokens as platform attestation tokens?
* Not really as PATs, since they don't have the same semantics, especially given the discrepancy between PP and RATS architectures
* We could write something up and get in touch with PP folks, perhaps also with [SPICE](https://www.ietf.org/mailman/listinfo/spice) and [WIMSE](https://www.ietf.org/mailman/listinfo/wimse) BoF at IETF
* Update PKIX+RA to use credential exporter instead of hand-rolled binding mechanism
* Are there any issues regarding use of load-balancers and how that impacts the binding steps?
* PR for first draft of using early exporter is [here](https://github.com/yaronf/draft-tls-attestation/pull/25)
* Split between TEE and REE (what happens within TEE and what is outside) for Confidential Computing use case
* It depends on the use-case:
* CC use-case: whole stack is in the TEE, so everything is attested through the enclave attestation
* IoT on-boarding use-case: only cryptographic functionality is in TEE, TLS stack is in REE (still measured and attester)

# Meeting 29/09/23

* We should get in touch with folks from INRIA (Karthik Bhargavan et al) who have extensive experience in formal verification of TLS
* Also the ProVerif folks - Bruno Blanchet, Vincent Cheval
* Need to contact Mike Bursell to see if there is any interest on his side on using TLS-A
* No current update on the keyID issue
* Updated the distribution of schemes with regard to their position relative to the handshake (pre-/intra-/post).
* No options within the handshake, apart from the protocol described by Carsten et al in their paper from a year ago.
* They use OpenSSL and have a bespoke way of linking the TLS handshake to RA (since they don't attest the TIK)
* Could probably use something like LURK or credential exporter instead
* For CC workloads, the server stack (maybe without the low-level networking functionality) should be inside the enclave
* This gives the RP the required guarantees about the attester, mitigates an attacker potentially taking control of the channel
* Can be used for the client, server, or both
* Though we need to make it clearer how it'll look in the mTLS case

# Meeting 22/09/23

* Usama presented at CCC Mini-Summit at OSS Europe in Bilbao
* Fairly small physical attendance, apparently not that much interest in Europe, organizers claimed 100+ virtual attendees
* Had a chat with Mike Bursell, will get in touch to see if he has anything in the works that could use our work
* Usama: looking through draft, there seems to be no reason as to why we need this work
* By comparison, Arto's paper gives a good motivation ('TLS gives no protection against compromised endpoints')
* If we give a motivation of 'we have this gap in security, we need to plug it somehow', this will lead to RA as a solution
* Then we can focus on where RA happens in respect to TLS HS (pre-/intra-/post-)
* What is the role of the KAK in attested TLS with CCA as Attester?
* We don't really have a KAK, but the RAK works similarly, through delegation, and is what we'll be using to attest the TIK using a side-car to the realm token
* Short answer: KAK (and KAT) is not relevant in the case of CCA realms
* What does RA cover - does it cover just the TIK, or does it also cover some of the TLS software stack?
* It depends on what you need to have in the Target Environment to achieve your security requirements
* Just attesting key? Also cover firmware/bootloader/OS...?
* Similar to a conversation about [this new ID](https://lamps-wg.github.io/csr-attestation/draft-ietf-lamps-csr-attestation.txt)
* In the context of CC, is it worth it to just protect the key? Does that actually bring any benefits over protecting with a TPM or HSM?
* Need more time to think about this.
* Could the RA nonce be generated by the RP instead of the verifier?
* There probably are options - the RP could generate a random nonce and send it across along with the AT.
* But this puts more responsibility on the client, do we trust that?
* Similar solutions have been done in the past in other contexts, but it bring a bunch of overhead.

# Half-day workshop, 03/07/23

* Update on prototyping effort:
* Deep dive into the current state of the end-to-end prototype, and what our plans are for it.
* What other directions and avenues should we explore (e.g., OpenSSL integration)?
* IETF drafts: What IETF drafts do we have pending, and which need more work?
* Formal verification: what is the plan for formal verification of the TLS extensions?
* Research paper/conference submissions: what are the goals and milestones?

## Useful links

* [IETF TLS WG Datatracker](https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/)
* [CCC Attestation subproject repo (home of prototype)](https://github.com/CCC-Attestation/attested-tls-poc)
* [IETF TLS WG Draft repo](https://github.com/yaronf/draft-tls-attestation)

## Notes (primarily from formal verification perspective): Ionut presentation
* TLS extensions
* Drafts and implementation are currently focused on Background check model, so from formal verification perspective we can also focus on Background check model. Thomas: Passport model is becoming increasingly important.
* Mutual attestation
* Alongside or without x.509 certs
* Key Attestation Token (KAT) draft: Key attestation here means the key generated inside Realm instance -- in contrast to key (RAK) of RMM.
* Currently TPM2.0 as RoT: Arm CCA is also supported, but not yet open-source
* Check out for CCA https://github.com/CCC-Attestation/attested-tls-poc/blob/main/doc/parsec-evidence-cca.md
* Relying Party as TLS server
* https://www.ietf.org/archive/id/draft-fossati-tls-attestation-03.html#section-5.2
* https://datatracker.ietf.org/doc/html/rfc5705

## Notes formal verification
* How many parties? as realistic as possible
* Important changes in TLS
* nonce
* PoP
* Start from RA (TEE) or TLS?
* Are proposed extensions major changes?
* Prepare a summary of TLS artifacts [see list](https://wiki.ietf.org/en/group/ufm)
* Variations of TLS protocol (unilateral vs. mutual authentication): which one do we focus on?
* ProVerif vs. Tamarin
* no preference
* Mapping to CCA: [IETF TLS WG Draft repo](https://github.com/yaronf/draft-tls-attestation) is probably outdated.
* TIK = Realm ephemeral key
* KAK = RAK
* PAK = CPAK
* KATAID = ?
* Properties: preserve all existing props
* [Appendix E of TLS draft 8446](https://datatracker.ietf.org/doc/html/rfc8446#appendix-E)
* Action for Thomas: sequence diagrams for RA+TLS for CCA [here](https://github.com/yaronf/draft-tls-attestation/blob/main/collaterals/cca.md)