[seal] Re: WG Review: Secure Evidence and Attestation Layer (seal)

[Eric Rescorla <[e-mail]>]

On Mon, Sep 22, 2025 at 4:13 AM Muhammad Usama Sardar <
[e-mail]> wrote:

> On 20.09.25 22:23, Eric Rescorla wrote:
>
> In any case, the relevant security feature from the peer's perspective is
> binding to the application traffic keys, because the relevant property is
> knowing you are sending to the attested endpoint.
>
> We discussed this today and we could not understand your reasoning for why
> exactly you think binding Evidence to *handshake* traffic keys is
> *insufficient* and why binding Evidence to *application* traffic keys is
> *necessary*. Surely having more stuff up to ServerFinished is good but
> the question is: is it really better?
>

I'm not sure why you think that this needs to be resolved at charter time.
Surely, this is a question for the WG.


> Handshake traffic keys contain contribution up to ServerHello, which
> implies that Client's DH key g^x and Server's DH key g^y are both covered.
> Binding to application traffic keys would additionally cover also the
> server's identity (assuming Certificate message contains a CA-signed cert)
> but a protocol design could put (hash of) identity (or cert) directly in
> the Evidence (via the 64-byte user-defined field). Proof-of-possession of
> the key, handshake integrity and key confirmation for shared secrets can be
> checked as usual. In that sense, it seems unclear whether binding Evidence
> to application (instead of handshake) traffic keys is a necessary property
> or just a defense-in-depth.
>
I'm not sure what sense you're using "binding" in.

As I said, the relevant technical property from the peer's perspective is
that it is sending to and receiving from the attested endpoint. That
traffic is protected by the application traffic keys, not by the handshake
traffic keys. In fact, it would be fine from this perspective if the
handshake weren't encrypted at all. Now, it may (or may not) be technically
fine to have attestation only to the portion of the transcript that is used
to generate the handshake traffic keys, but I don't think it's useful to
think of this as binding it to the handshake traffic keys.

-Ekr