MIME-Version: 1.0
References: 
 <176890236222.867028.3887971722243664931@dt-datatracker-865585c994-4fgh4>
 <651a244c-5c66-430e-a125-43d0161a06f7@tu-dresden.de>
In-Reply-To: <651a244c-5c66-430e-a125-43d0161a06f7@tu-dresden.de>
From: Yaroslav Rosomakho <yrosomakho@zscaler.com>
Date: Thu, 22 Jan 2026 15:27:32 +0700
Message-ID: 
 <CAMtubr2hmi6HVzohH-RZ1gydkkWex_b=3mk=W9Jj4jC-zk+Jgw@mail.gmail.com>
To: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
Content-Type: multipart/alternative; boundary="0000000000008a22970648f5d048"
Message-ID-Hash: DHYYKHEPNUAVDZTF7AN7VIM5HIDD5HNF
CC: "seat@ietf.org" <seat@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BSeat=5D_Re=3A_Fwd=3A_New_Version_Notification_for_draft-usama-s?=
	=?utf-8?q?eat-intra-vs-post-02=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/seat/gQTdMo0OexLffcB1x39M4J57Ug4>

--0000000000008a22970648f5d048
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Muhammad Usama Sardar <
muhammad_usama.sardar@tu-dresden.de> 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: internet-drafts@ietf.org
> To: Muhammad Sardar <muhammad_usama.sardar@tu-dresden.de>
> <muhammad_usama.sardar@tu-dresden.de>, Muhammad Usama Sardar
> <muhammad_usama.sardar@tu-dresden.de>
> <muhammad_usama.sardar@tu-dresden.de>
>
> 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.tx=
t
> 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=3Ddraft-usama-seat-intra-vs-pos=
t-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 -- seat@ietf.org
> To unsubscribe send an email to seat-leave@ietf.org
>

--=20


This communication (including any attachments) is intended for the sole=20
use=C2=A0of the intended recipient and may contain confidential, non-public=
,=20
and/or=C2=A0privileged material. Use, distribution, or reproduction of this=
=C2=A0
communication by unintended recipients is not authorized. If you received=
=C2=A0
this communication in error, please immediately notify the sender and then=
=C2=A0
delete all copies of this communication from your system.

--0000000000008a22970648f5d048
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Usama.<div><br></div><div>Here is my r=
eview as an individual contributor (not wearing any hats).</div><div><br></=
div><div>Overall, I find the discussion useful and the concrete implementat=
ion feedback (such as latency measurements) very valuable. I do think a few=
 conclusions are currently stated more strongly than the text supports.</di=
v><div><br></div><div>Section 3 (Pre-handshake attestation):<br><br></div><=
div>The current dismissal seems to assume Evidence can be arbitrarily old r=
elative to connection establishment. Many signed artifacts carry issuance t=
ime and validity constraints (e.g., JWT iat/exp [0], HTTP Message Signature=
s created/expires [1], SAML conditions [2]). A timestamp alone is not the s=
ame as freshness, but a short validity window plus a trustworthy time sourc=
e can be an acceptable assurance mechanism in some deployments. Likewise, s=
ome schemes can provide stronger freshness via verifier-chosen challenges o=
r monotonic counters. I suggest separating &quot;not contemporaneous with t=
his TLS connection&quot; from &quot;too old to be meaningful&quot;, and dis=
cussing under what threat models / deployment assumptions pre-handshake is =
insufficient.<br></div><div>Section 3 does not currently mention potential =
benefits of pre-handshake (e.g., no modification of TLS, no changes to appl=
ication protocols, potential caching/scalability advantages). Even if you u=
ltimately judge these insufficient, listing them would make the draft more =
balanced.</div><div><br></div><div>Section 4 (Intra-handshake attestation):=
</div><div><br>I don&#39;t think &quot;embedding evidence in the handshake&=
quot; 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 do=
esn&#39;t follow merely from being carried in handshake messages.<br>More g=
enerally, the text would benefit from explicitly stating what is being boun=
d to what (e.g., transcript hash, exporter, traffic secrets, application tr=
affic secrets) and which concrete mechanisms provide that binding.</div><di=
v><br></div><div>Section 4.1.2 / 4.2.4 (Round trips and latency):</div><div=
><br>The argument that avoiding an extra RTT is not a relevant goal may dep=
end heavily on deployment topology (LAN vs same-region vs cross-continent).=
 The data point you include is still helpful.<br>Section 4.2.4 (high handsh=
ake latency) seems closely related to 4.1.2; you might consider merging the=
m and broadening the analysis to include &quot;baseline handshake costs&quo=
t; (including how PQ transition may change the baseline).</div><div><br></d=
iv><div>Section 4.2.1 (Limited claims availability):</div><div><br>I&#39;m =
not convinced the limitation is specific to intra-handshake without a clear=
er definition. What exactly is meant by &quot;limited claims&quot;? Which c=
laims are unavailable intra-handshake but available pre- or post-handshake,=
 and why? Concrete examples (even a short list) would help.</div><div><br><=
/div><div>Section 4.2.2 (Invasive changes in TLS):</div><div><br></div><div=
>It&#39;s not clear to me that intra-handshake attestation inherently requi=
res modifications to the TLS key schedule. Could a design based on standard=
 TLS extensions and explicit transcript/channel binding (via early exporter=
s) satisfy the required security properties? If not, it would be useful to =
explain in the draft text which properties force more invasive changes.</di=
v><div><br></div><div>Section 5.1.4 (Latency placement):</div><div><br>I do=
n&#39;t think that moving latency related to attestation into after handsha=
ke=C2=A0is always a good thing. In some real-time and streaming application=
s, a spike after the session is established may be much more disruptive tha=
n paying a cost during the handshake. It would help to discuss this as a tr=
ade-off.</div><div><br></div><div>Section 5.1.6 (Ease of implementation):</=
div><div><br>A working demo is great, but I&#39;m not sure it translates di=
rectly into &quot;ease of implementation&quot; for production deployments. =
Production-oriented examples (especially showing Exported Authenticators us=
age) would make this argument much more compelling.</div><div><br></div><di=
v>Section 5.2.1 (Impact on application layer):</div><div><br>This is my big=
gest concern with the post-handshake approach as currently written. Exporte=
d Authenticators define a secure way to serialise and bind authenticators, =
but each application protocol still needs a way to negotiate, carry, and pr=
ocess those structures. So far, this has not been easy even for HTTP (HTTP =
working group=C2=A0is still focused only on unsolicited server-side authent=
icators [3]). I suggest expanding this section into a more concrete discuss=
ion of deployment paths, and what is realistically required in applications=
 and/or infrastructure.</div><div><br></div><div><br></div><div><br></div><=
div>The analysis appears to skip a potentially important design point: an e=
xplicit shim or gating layer that performs attestation after the TLS handsh=
ake completes but before any application data is exchanged. This is operati=
onally distinct from both intra-handshake attestation and fully application=
-integrated post-handshake attestation.=C2=A0Such an approach could preserv=
e standard TLS handshake behaviour and latency characteristics, avoid invas=
ive TLS changes, and still prevent application data from flowing until atte=
station succeeds. It may also mitigate some of the application-layer comple=
xity by localizing attestation handling to a well-defined enforcement point=
 (e.g., a sidecar or connection gate) rather than requiring per-protocol in=
tegration.</div><div><br></div><div>Is there a specific reason this design =
point was excluded? If not, it may be worth explicitly analysing it as a di=
stinct option, or clarifying whether and why it is considered equivalent to=
 &quot;post-handshake&quot; in the current text.</div><div><br></div><div><=
br></div><div>Hope this helps.</div><div><br></div><div>Best Regards,</div>=
<div>Yaroslav</div><div><br></div><div>[0]=C2=A0<a href=3D"https://www.rfc-=
editor.org/rfc/rfc7519.html#section-4.1.6">https://www.rfc-editor.org/rfc/r=
fc7519.html#section-4.1.6</a></div><div>[1]=C2=A0<a href=3D"https://www.rfc=
-editor.org/rfc/rfc9421.html#signature-params">https://www.rfc-editor.org/r=
fc/rfc9421.html#signature-params</a></div><div>[2]=C2=A0<a href=3D"https://=
docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">https://docs.o=
asis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf</a></div><div>[3] <a =
href=3D"https://datatracker.ietf.org/doc/draft-ietf-httpbis-secondary-serve=
r-certs">https://datatracker.ietf.org/doc/draft-ietf-httpbis-secondary-serv=
er-certs</a></div></div><br><div class=3D"gmail_quote gmail_quote_container=
"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 20, 2026 at 5:29=E2=80=
=AFPM Muhammad Usama Sardar &lt;<a href=3D"mailto:muhammad_usama.sardar@tu-=
dresden.de">muhammad_usama.sardar@tu-dresden.de</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

 =20

   =20
 =20
  <div>
    <p>Hi,</p>
    <p>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!<br>
    </p>
    <div>
      <p>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.</p>
      <p>Looking forward to your ideas to mutually work to improve it.</p>
      Thanks!</div>
    <div><br>
    </div>
    <div>-Usama<br>
    </div>
    <div><br>
    </div>
    <div>[0]
      <a href=3D"https://lists.confidentialcomputing.io/g/attestation/messa=
ge/276" target=3D"_blank">https://lists.confidentialcomputing.io/g/attestat=
ion/message/276</a><br>
      <br>
      -------- Forwarded Message --------
      <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0">
        <tbody>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">Subject:
            </th>
            <td>New Version Notification for
              draft-usama-seat-intra-vs-post-02.txt</td>
          </tr>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">Date: </th>
            <td>Tue, 20 Jan 2026 01:46:02 -0800</td>
          </tr>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">From: </th>
            <td><a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blan=
k">internet-drafts@ietf.org</a></td>
          </tr>
          <tr>
            <th valign=3D"BASELINE" nowrap align=3D"RIGHT">To: </th>
            <td>Muhammad Sardar
              <a href=3D"mailto:muhammad_usama.sardar@tu-dresden.de" target=
=3D"_blank">&lt;muhammad_usama.sardar@tu-dresden.de&gt;</a>, Muhammad
              Usama Sardar <a href=3D"mailto:muhammad_usama.sardar@tu-dresd=
en.de" target=3D"_blank">&lt;muhammad_usama.sardar@tu-dresden.de&gt;</a></t=
d>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      A new version of Internet-Draft
      draft-usama-seat-intra-vs-post-02.txt has been<br>
      successfully submitted by Muhammad Usama Sardar and posted to the<br>
      IETF repository.<br>
      <br>
      Name: draft-usama-seat-intra-vs-post<br>
      Revision: 02<br>
      Title: Pre-, Intra- and Post-handshake Attestation<br>
      Date: 2026-01-20<br>
      Group: Individual Submission<br>
      Pages: 18<br>
      URL:
      <a href=3D"https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-=
post-02.txt" target=3D"_blank">https://www.ietf.org/archive/id/draft-usama-=
seat-intra-vs-post-02.txt</a><br>
      Status:
      <a href=3D"https://datatracker.ietf.org/doc/draft-usama-seat-intra-vs=
-post/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-usama-seat=
-intra-vs-post/</a><br>
      HTML:
      <a href=3D"https://www.ietf.org/archive/id/draft-usama-seat-intra-vs-=
post-02.html" target=3D"_blank">https://www.ietf.org/archive/id/draft-usama=
-seat-intra-vs-post-02.html</a><br>
      HTMLized:
      <a href=3D"https://datatracker.ietf.org/doc/html/draft-usama-seat-int=
ra-vs-post" target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-u=
sama-seat-intra-vs-post</a><br>
      Diff:
<a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-usama-seat-int=
ra-vs-post-02" target=3D"_blank">https://author-tools.ietf.org/iddiff?url2=
=3Ddraft-usama-seat-intra-vs-post-02</a><br>
      <br>
      Abstract:<br>
      <br>
      This document presents a taxonomy of extending TLS protocol with<br>
      remote attestation, referred to as attested TLS. It also presents<br>
      high-level analysis of benefits and limitations of each category,<br>
      namely pre-handshake attestation, intra-handshake attestation and<br>
      post-handshake attestation.<br>
      <br>
      <br>
      <br>
      The IETF Secretariat<br>
      <br>
      <br>
    </div>
  </div>

_______________________________________________<br>
Seat mailing list -- <a href=3D"mailto:seat@ietf.org" target=3D"_blank">sea=
t@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:seat-leave@ietf.org" targ=
et=3D"_blank">seat-leave@ietf.org</a><br>
</blockquote></div></div>

<br>
<div><span style=3D"color:rgb(69,84,100);font-family:SourceSansPro,&quot;He=
lvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:12px"><br></span></=
div><span style=3D"color:rgb(69,84,100);font-family:SourceSansPro,&quot;Hel=
vetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:12px">This communica=
tion (including any attachments) is intended for the sole use=C2=A0</span><=
span style=3D"color:rgb(69,84,100);font-family:SourceSansPro,&quot;Helvetic=
a Neue&quot;,Helvetica,Arial,sans-serif;font-size:12px">of the intended rec=
ipient and may contain confidential, non-public, and/or=C2=A0</span><span s=
tyle=3D"color:rgb(69,84,100);font-family:SourceSansPro,&quot;Helvetica Neue=
&quot;,Helvetica,Arial,sans-serif;font-size:12px">privileged material. Use,=
 distribution, or reproduction of this=C2=A0</span><span style=3D"color:rgb=
(69,84,100);font-family:SourceSansPro,&quot;Helvetica Neue&quot;,Helvetica,=
Arial,sans-serif;font-size:12px">communication by unintended recipients is =
not authorized. If you received=C2=A0</span><span style=3D"color:rgb(69,84,=
100);font-family:SourceSansPro,&quot;Helvetica Neue&quot;,Helvetica,Arial,s=
ans-serif;font-size:12px">this communication in error, please immediately n=
otify the sender and then=C2=A0</span><span style=3D"color:rgb(69,84,100);f=
ont-family:SourceSansPro,&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-se=
rif;font-size:12px">delete all copies of this communication from your syste=
m.</span>
--0000000000008a22970648f5d048--