[CFRG] Re: On the applied cryptography of Attested TLS

[Nathanael Ritz <[e-mail]>]

Hi Islam,

Thanks for your thoughts. I have branched this email thread [*] to the SEAT
mailing list, as the cryptographic argument has already been raised in the
CFRG and I have some comments regarding RFC9266 and seat-expat that I
believe the SEAT WG should consider directly, thanks.

Cheers,
Nathanael

[*] https://mailarchive.ietf.org/arch/msg/seat/s5btit7L8WUaxPNwdXs4rCr3l98/

On Fri, 6 Nov 2026 at 12:48, ABOUBAKAROV Islam <islam.aboubakarov=
[e-mail]> wrote:

> Hi everyone,
>
> I am Islam Aboubakarov, a researcher at ESILV, Pole Leonard de Vinci,
> France, and one of the co-authors of draft-intra-handshake-fail.
>
> The channel binding for standard TLS 1.3 are explained in RFC9266. In
> early attestation, attestation evidence is generated even before the
> traffic keys are generated. Hence, there is no binding to the connection.
>
> In standard TLS 1.3, any software component in the whole server may have
> access to keys. In attested TLS, only the Attester has access to keys. This
> is the change in threat model. The question for this research group is:
> When using only ServerHello as the binder, the channel binding does not
> exist for normal server, how can it exist under attestation threat model?
>
> All vendors have validated all security advisories and CVEs in my draft.
> We have also shared our findings with all stakeholders, e.g. GA4GH, CCC,
> AAIF and RIPE [1]. We have not received any disagreement on any of those.
> We also presented our analysis in CFRG-125, and there was no technical
> objection from the research group [2]. The question for research group
> is: from a cryptographic perspective, does someone see anything wrong in
> the CVEs?
>
> >From practical perspective, early attestation adds latency of attestation
> evidence within handshake. This can result in latency and timeout failures
> [3].
>
> Respectfully,
> Islam
>
> [1]
> *https://www.ietf.org/archive/id/draft-intra-handshake-fail-61.html#section-20.1.2*
> <https://www.ietf.org/archive/id/draft-intra-handshake-fail-61.html#section-20.1.2>
> [2]
> *https://datatracker.ietf.org/doc/minutes-125-cfrg-202603190100/#1045---muhammad-usama-sardar-relay-attacks-in-intra-handshake-attestation-and-proposed-solution-in-post-handshake-attestation-15-mins*
> <https://datatracker.ietf.org/doc/minutes-125-cfrg-202603190100/#1045---muhammad-usama-sardar-relay-attacks-in-intra-handshake-attestation-and-proposed-solution-in-post-handshake-attestation-15-mins>
> [3] Section 7.4 in
> *https://www.researchgate.net/publication/414529199_EarlyAttestationBleed_Three_Critical-severity_Vulnerabilities_of_CVSS_90_in_Confidential_Computing*
> <https://www.researchgate.net/publication/414529199_EarlyAttestationBleed_Three_Critical-severity_Vulnerabilities_of_CVSS_90_in_Confidential_Computing>
>
>
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>