# Background and motivation

In many scenarios, particularly with the rise of Trusted Execution
Environments (TEEs) and the increasing security demands for IoT devices
and confidential workloads, there is a requirement for some use cases that
utilize protocols such as (D)TLS to also ensure that the peer's state,
expressed as Claims (for example about code, data and configurations),
is validated and when authenticating, also bound to the conventional
authentication (verification of identity).

Remote attestation (RFC9334) addresses this by allowing an entity to
produce Evidence and Attestation Results about its current state. For
example to prove that its software and firmware haven't been tampered
with. Or to prove that a secure boot method is enabled. Or to prove
that cryptographic keys are securely stored within a hardware-protected
environment.

Remote attestation bound to the authenticated TLS connection provides an
additional assurance of trustworthiness that can prevent communication
to a compromised or unauthorized system.

# Scope

The Secure Evidence and Attestation Transport (SEAT) WG will document a
set of use cases that protocols such as (D)TLS should be able to support.
It will initially deliver a Standards Track protocol that meets these
use cases and enables peer or mutual attestation for (D)TLS using the
extension and/or exporter features of D(TLS). Mutual attestation will
be supported with and without client TLS authentication to faciliate
anonymous client attestation.

Such a protocol would allow an entity to produce Evidence or an
Attestation Result about itself for another party to evaluate.

Specific scoping:

- This effort will be restricted to leveraging the (D)TLS 1.3 protocol
   and an attestation binding to a (D)TLS 1.3 connection. (D)TLS
   1.2 and older will not be supported.

- It will leverage the existing RATS WG documents to ensure
   interoperability with existing and future attestation technologies.

- The attested (D)TLS protocol extension will focus on attestation with TLS
   server authentication, and with or without TLS client authentication. No
   new TLS authentication mechanisms will be created.

- The attested (D)TLS protocol extension will not modify the (D)TLS
   protocol itself. It may define (D)TLS extensions to support its goals
   but will not modify, add, or remove any existing protocol messages
   or modify the key schedule.

- The attested D(TLS) protocol extension will also describe a minimum
   subset of properties that the attested state must convey in order
   to bind the Evidence and Attestation Results to the TLS connection.

- 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 effort will not create solutions that decrease the privacy
   or security properties of generic (D)TLS connections.

The working group will engage with the research community on the
evaluation and formal analysis of the protocol artifacts in parallel
with the specification work.

# Dependencies and Liaisons

- The working group will work closely with the TLS Working Group, the
   RATS working group, and the Confidential Computing Consortium's
   (CCC's) Attestation Special Interest Group (SIG).

- The working group will engage with research groups regarding
   formal analysis of the working groups's resulting work.

# Future work

After the initial Milestones are complete, the WG may recharter to work
on adding attestation to protocols other than (D)TLS, such as IKEv2 or
SSH, provided there is sufficient interest.