[Seat] The Passport Model-sized elephant in the room

[Nathanael Ritz <[e-mail]>]

Hi everyone,

Leading into the IETF126 meeting for the SEAT WG, I wanted to put some
emphasis on a significant requirement from the SEAT charter:

## The challenge

=> The attested (D)TLS protocol extension will allow per-connection
[freshness] (https://www.ietf.org/rfc/rfc9334.html#section-10)
of Evidence **and Attestation Results**.

The challenge the charter requirement gives us when the TLS client is the
RP and the TLS server is the Attester is that we do not seem to have a
common understanding (let alone a performant approach) for binding a cached
Attestation Result (AR) on a per-connection basis.

For example, `fossati-seat-early-attestation-05` does not suggest a binder
mechanism for Attestation Results:

  "Freshness of the exchanged Evidence is guaranteed through an Attestation
   Binder mechanism (see Section 5.1) when the Background Check Model is
   in use. *In the Passport Model, freshness expectations are more relaxed*
   and are governed by the lifetime of the signed Attestation Results" [1]

And likewise, while `fossati-seat-expat-03` has a detailed section for a
binder mechanism associated with the Background-Model in Sect. 4, the
details for the passport model are notably terse, in comparision:

  "Verify the Attestation Result: The Relying Party MUST check that the
  Attestation Result is correctly signed by the issuing authority and that
  it meets the Relying Party’s security requirements." [2]

The challenge is exacerbated further by the lack of compound
authentication. As while an Attestation Result **should** contain
assertions relating to the attester's TLS identity key, neither the
Verifier's trusted signature nor the TEE's own Attestation Environment
signing key can be used to provide backup assurance should the CA-backed
key be compromised in some way. This means that the additional assurances
available from the Background-Check model vanish under the Passport model,
which also make it a non-starter for use cases like the one recently shared
by Markus [3].

---

## A proposal for compound authentication with the passport model over TLS
1.3

As mentioned before, an Attestation Result **should** contain assertions
relating to the attester's TLS identity key. If a target environment for a
specific machine is also configured to generate an ephemeral asymmetric KEM
key (such as ECDH-KEM or ML-KEM) and include it in an Attester's assertions
in Evidence, we can use it in such a way that provides an entirely
independent trust anchor from the TLS identity signing key.

This email is already over-long, but I have prepared a visual and example
algorithm for just how this kind of mechanism could work, for anyone
morbidly curious: https://notes.ietf.org/s/df_yhjF6F2. This approach
doesn't apply strictly to TLS, my research so far suggests it works just
the same for EDHOC RA.

With further discussion, I am sure this approach can be refined.
Thankfully, it seems like other schemes (such as client as Attester and
server as RP) seem to be easier logic puzzles.

Thanks for reading!

Cheers,
Nathanael


[1]
https://www.ietf.org/archive/id/draft-fossati-seat-early-attestation-05.html#section-4-1

[2]
https://www.ietf.org/archive/id/draft-fossati-seat-expat-03.html#section-4-4.2.1

[3] https://mailarchive.ietf.org/arch/msg/seat/whMijUHurwGZBMhmV_Eqa1PG7w4/