[seal] Re: Proposed update to SEAL charter

[Paul Wouters <[e-mail]>]

On Mon, Sep 29, 2025 at 6:09 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi Paul,
>
> Thank you for updates on the charter. I see that a few of the comments
> were not accommodated. I didn't see any explicit reason in the preamble of
> your email to not accommodate those. If there is a reason, please clarify.
>

There were lots of comments and discussion. I didnt think all needed
changes or did it differently from what you or ekr suggested. Let me know
where
you think this is still an issue.

On 29.09.25 21:42, Paul Wouters wrote:
>
>
> New Charter text:
>
> # Background and motivation
>
> 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.
>
> Editorial: Ekr correctly mentioned that except for first sentence, these
> are all phrases and not full sentences. My proposed new text for this is in
> [0].
>

I had added verbs to those sentences. I didn't like the ",or" construct.

> This provides an additional assurance of trustworthiness that can
> prevent communication to a compromised or unauthorized system.
>
> "This" here is ambiguous. The paragraph before this was referring to
> remote attestation. However, this statement is not true for remote
> attestation, which alone does not provide any "additional" assurance.
> Remote attestation alone may be actually worse than TLS, as remote
> attestation may result in relay and diversion attacks. My proposed new text
> for this is in [0].
>

I didn't like the use of "composition". We can change "This" to "Remote
attestation bound to the authenticated TLS connection"


> # Scope
>
> I see Ekr's proposal is missing here. Ekr and I mutually agreed on this
> text (to which nobody objected) [0]:
>
> This protocol will also describe a minimum subset of properties
> that the attested remote state must ensure in order to bind the
> Evidence and Attestation Results to the TLS connection.
>
My idea is that these determinations follow from properly specified use
cases. I wasn't sure if "this protocol
describes" would be valid. Possibly it would just be claims in the
attestation and it would be up for interpretation
of the attestation results on whether the binding has the right properties.
Eg I am not yet convinced this is a part
of the protocol or only part of "interpretating the attestation", and thus
not part of the protocol itself.



> Specific scoping:
>
> - The attested (D)TLS protocol will focus on attestation and authenticated
>   attestation, but will not create new authentication mechanisms.
>
> As I mentioned in the WG comments, I have never heard of "authenticated
> attestation". My proposed new text for this is in [0].
>

Again, I didn't like the use of the word "composition". We could say
"attestation with and without TLS authentication. but will not
create new TLS authentication mechanisms" ?


> - The attested (D)TLS protocol will not modify the (D)TLS protocol outside
>   of adding (D)TLS extensions to support its goals. It will not modify
>   any existing protocol messages or the key schedule.
>
> Two of my proposed solutions are based on the following. So I would like
> some clarity on:
>
> With extensions, one could add new messages *without* modifying existing
> messages or key schedule. Is that in scope?
>
I think adding extension payloads to existing messages is in scope.
Designing a whole new exchange with additional RTT is not.

> Is supporting new signature algorithms in scope?
>
That would probably be a hack that would need a very solid argumentation of
why one would go that way.

>
> - A Standards Track document defining a (D)TLS protocol solution [...]
>
> Does a "solution" entail anything more than a protocol? If yes, what is
> it?
>
If not, as I proposed in [0]: s/a (D)TLS protocol solution/an attested
> (D)TLS protocol
>

changed to  "an attested (D)TLS protocol extension"

>
> In future work, s/D(TLS)/(D)TLS
>

Fixed.

For completeness, the new updated text pasted below.

Paul

# 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 Layer (SEAL) 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 will focus on attestation with and without
  TLS authentication. but will not create new TLS authentication mechanisms.

- The attested (D)TLS protocol will not modify the (D)TLS protocol outside
  of adding (D)TLS extensions to support its goals. It will not modify
  any existing protocol messages or the key schedule.

- The attested (D)TLS protocol 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.

# (Proposed) Milestones

- A use cases document describing the scenarios that this
  working group will be targeting in its specification document.
  This document need not be published as an RFC.

- A Standards Track document defining an attested (D)TLS protocol extension
  supporting remote peer and mutual attestation bound to the (D)TLS
  connection.

# 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.