[Seat] Re: Fwd: New Version Notification for draft-usama-seat-intra-vs-post-02.txt

[Yaroslav Rosomakho <[e-mail]>]

Hi Usama.

Here is my review as an individual contributor (not wearing any hats).

Overall, I find the discussion useful and the concrete implementation
feedback (such as latency measurements) very valuable. I do think a few
conclusions are currently stated more strongly than the text supports.

Section 3 (Pre-handshake attestation):

The current dismissal seems to assume Evidence can be arbitrarily old
relative to connection establishment. Many signed artifacts carry issuance
time and validity constraints (e.g., JWT iat/exp [0], HTTP Message
Signatures created/expires [1], SAML conditions [2]). A timestamp alone is
not the same as freshness, but a short validity window plus a trustworthy
time source can be an acceptable assurance mechanism in some deployments.
Likewise, some schemes can provide stronger freshness via verifier-chosen
challenges or monotonic counters. I suggest separating "not contemporaneous
with this TLS connection" from "too old to be meaningful", and discussing
under what threat models / deployment assumptions pre-handshake is
insufficient.
Section 3 does not currently mention potential benefits of pre-handshake
(e.g., no modification of TLS, no changes to application protocols,
potential caching/scalability advantages). Even if you ultimately judge
these insufficient, listing them would make the draft more balanced.

Section 4 (Intra-handshake attestation):

I don't think "embedding evidence in the handshake" automatically
guarantees freshness. Freshness typically depends on an unpredictable,
single-use challenge and clear replay handling. If Evidence (or the
challenge it is bound to) can be reused, the freshness property doesn't
follow merely from being carried in handshake messages.
More generally, the text would benefit from explicitly stating what is
being bound to what (e.g., transcript hash, exporter, traffic secrets,
application traffic secrets) and which concrete mechanisms provide that
binding.

Section 4.1.2 / 4.2.4 (Round trips and latency):

The argument that avoiding an extra RTT is not a relevant goal may depend
heavily on deployment topology (LAN vs same-region vs cross-continent). The
data point you include is still helpful.
Section 4.2.4 (high handshake latency) seems closely related to 4.1.2; you
might consider merging them and broadening the analysis to include
"baseline handshake costs" (including how PQ transition may change the
baseline).

Section 4.2.1 (Limited claims availability):

I'm not convinced the limitation is specific to intra-handshake without a
clearer definition. What exactly is meant by "limited claims"? Which claims
are unavailable intra-handshake but available pre- or post-handshake, and
why? Concrete examples (even a short list) would help.

Section 4.2.2 (Invasive changes in TLS):

It's not clear to me that intra-handshake attestation inherently requires
modifications to the TLS key schedule. Could a design based on standard TLS
extensions and explicit transcript/channel binding (via early exporters)
satisfy the required security properties? If not, it would be useful to
explain in the draft text which properties force more invasive changes.

Section 5.1.4 (Latency placement):

I don't think that moving latency related to attestation into after
handshake is always a good thing. In some real-time and streaming
applications, a spike after the session is established may be much more
disruptive than paying a cost during the handshake. It would help to
discuss this as a trade-off.

Section 5.1.6 (Ease of implementation):

A working demo is great, but I'm not sure it translates directly into "ease
of implementation" for production deployments. Production-oriented examples
(especially showing Exported Authenticators usage) would make this argument
much more compelling.

Section 5.2.1 (Impact on application layer):

This is my biggest concern with the post-handshake approach as currently
written. Exported Authenticators define a secure way to serialise and bind
authenticators, but each application protocol still needs a way to
negotiate, carry, and process those structures. So far, this has not been
easy even for HTTP (HTTP working group is still focused only on unsolicited
server-side authenticators [3]). I suggest expanding this section into a
more concrete discussion of deployment paths, and what is realistically
required in applications and/or infrastructure.



The analysis appears to skip a potentially important design point: an
explicit shim or gating layer that performs attestation after the TLS
handshake completes but before any application data is exchanged. This is
operationally distinct from both intra-handshake attestation and fully
application-integrated post-handshake attestation. Such an approach could
preserve standard TLS handshake behaviour and latency characteristics,
avoid invasive TLS changes, and still prevent application data from flowing
until attestation succeeds. It may also mitigate some of the
application-layer complexity by localizing attestation handling to a
well-defined enforcement point (e.g., a sidecar or connection gate) rather
than requiring per-protocol integration.

Is there a specific reason this design point was excluded? If not, it may
be worth explicitly analysing it as a distinct option, or clarifying
whether and why it is considered equivalent to "post-handshake" in the
current text.


Hope this helps.

Best Regards,
Yaroslav

[0] https://www.rfc-editor.org/rfc/rfc7519.html#section-4.1.6
[1] https://www.rfc-editor.org/rfc/rfc9421.html#signature-params
[2] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
[3]
https://datatracker.ietf.org/doc/draft-ietf-httpbis-secondary-server-certs

On Tue, Jan 20, 2026 at 5:29 PM Muhammad Usama Sardar <
[e-mail]> wrote:

> Hi,
>
> This version replaces our experiments with the experiments of Markus Rudy
> as independent data point. It also addresses the feedback [0] from Mike
> Bursell, the Executive Director of Confidential Computing Consortium (CCC).
> Thanks both!
>
> I welcome WG feedback/thoughts/critique on the draft. In case of critique,
> please propose text and provide references, if possible, to support your
> views. I request the same if you disagree with something.
>
> Looking forward to your ideas to mutually work to improve it.
> Thanks!
>
> -Usama
>
> [0] https://lists.confidentialcomputing.io/g/attestation/message/276
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-usama-seat-intra-vs-post-02.txt
> Date: Tue, 20 Jan 2026 01:46:02 -0800
> From: [e-mail]
> To: Muhammad Sardar <[e-mail]>
> <[e-mail]>, Muhammad Usama Sardar
> <[e-mail]>
> <[e-mail]>
>
> A new version of Internet-Draft draft-usama-seat-intra-vs-post-02.txt has
> been
> successfully submitted by Muhammad Usama Sardar and posted to the
> IETF repository.
>
> Name: draft-usama-seat-intra-vs-post
> Revision: 02
> Title: Pre-, Intra- and Post-handshake Attestation
> Date: 2026-01-20
> Group: Individual Submission
> Pages: 18
> URL: https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-post-02.txt
> Status: https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs-post/
> HTML:
> https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-post-02.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-usama-seat-intra-vs-post
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-usama-seat-intra-vs-post-02
>
> Abstract:
>
> This document presents a taxonomy of extending TLS protocol with
> remote attestation, referred to as attested TLS. It also presents
> high-level analysis of benefits and limitations of each category,
> namely pre-handshake attestation, intra-handshake attestation and
> post-handshake attestation.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> Seat mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 


This communication (including any attachments) is intended for the sole 
use of the intended recipient and may contain confidential, non-public, 
and/or privileged material. Use, distribution, or reproduction of this 
communication by unintended recipients is not authorized. If you received 
this communication in error, please immediately notify the sender and then 
delete all copies of this communication from your system.