Return-Path: X-Original-To: lake@mail2.ietf.org Delivered-To: lake@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9A575C3A5B99 for ; Tue, 3 Mar 2026 11:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -4.395 X-Spam-Level: X-Spam-Status: No, score=-4.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhpqnbA-WBWz for ; Tue, 3 Mar 2026 11:21:09 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 156D7C3A5B8C for ; Tue, 3 Mar 2026 11:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=UCWtc0qAHTm9zkK5hHK2LE+Rj10Rh7kygKj+c3wkNFA=; b=nBORg+iI+QATZnocwbxc9zatU90JoWy56LJFf+vk2r3sMAo8Or1iFcv1 mj2CczNw5QZVtb4ux3jWG+VYDIK78vmuu8NRrlTDsSyOBGsAPtv+k4dOM uxf+tGLLy8SMvdstmDTqeZrbJyfl1n0PDMMjKVKyc4TgqWPGmh1C1Upmi M=; X-CSE-ConnectionGUID: ZbSYiyLARD6251yc3bakZw== X-CSE-MsgGUID: 6ZQZh4VtSi+m6DiCxoYAqg== Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=malisa.vucinic@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.21,322,1763420400"; d="scan'208,217";a="140325794" Received: from unknown (HELO smtpclient.apple) ([31.204.253.99]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2026 20:21:08 +0100 From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Message-Id: <972EE59F-0214-4759-884E-1213503B94C8@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_D9AA8AAB-266B-47B9-AF8C-59194120FA2F" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\)) Date: Tue, 3 Mar 2026 20:20:56 +0100 In-Reply-To: <2386e955-426e-4e19-ace2-0220d6552be4@tu-dresden.de> To: Muhammad Usama Sardar References: <5521ffe4-4f9f-4470-93a2-644841713996@tu-dresden.de> <2386e955-426e-4e19-ace2-0220d6552be4@tu-dresden.de> X-Mailer: Apple Mail (2.3826.700.81.1.4) Message-ID-Hash: L6QUFNZL6NAMYBTPZDUQMX4XN4S2ZMPV X-Message-ID-Hash: L6QUFNZL6NAMYBTPZDUQMX4XN4S2ZMPV X-MailFrom: malisa.vucinic@inria.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "lake@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BLake=5D_Re=3A_=5BUfmrg=5D_Relay_Attacks_in_Intra-handshake_Atte?= =?utf-8?q?station_for_Confidential_Agentic_AI_Systems?= List-Id: Lightweight Authenticated Key Exchange Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_D9AA8AAB-266B-47B9-AF8C-59194120FA2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Usama, Thanks for sharing, insightful. I added a 5-minute slot to the agenda as = I understand that it would relate to EDHOC, not TLS. Looking at the Relay Attack Scenario and the corresponding figure in = [9], I would like to confirm with you that the Attacker maintains two = separate sessions, one with the Relying Party and the other with the = Attester (Legitimate Agent)? I might be missing something from [9], but I don=E2=80=99t quite = understand the link between the three Bindings Levels that you define = and the actual mitigation of the attack. The attack that is explained in = Relay Attack Scenario in [9] seems to be mitigated already with Binding = Level 1 - shared DH secret. Is that correct? If so, the detail that I do = not understand is which attack(s) are Level 2 and Level 3 bindings = protecting against? Best, Mali=C5=A1a > On Mar 3, 2026, at 19:01, Muhammad Usama Sardar = wrote: >=20 > Hi lakers, >=20 > Following up with supporting public evidence: Cocos AI has publicly = acknowledged [9] the relay attacks last Friday.=20 >=20 > # Context >=20 > As helpful context, Cocos AI [4] claimed their attested TLS to be the = "best in the world" in the Confidential Computing Consortium and despite = we having informed them repeatedly about the attacks after our formal = analysis, they were continuing to misguide the community on social = media. Anyway, we now respect their honesty and transparency, and we = remain fully committed to helping them towards secure solutions. >=20 > # Cocos AI acknowledgment of attacks >=20 > Cocos AI (one of the implementers of the protocol) has publicly = acknowledged [9] our email and the relay attacks we highlighted on their = design and implementation in our email. Particularly, see the sections = "Limitations and the Relay Attack" and "The Relay Attack Scenario" in = [9]. Note that their description is almost a paraphrase of our email. = There are some nits that we disagree with them but that doesn't matter = much. They have essentially acknowledged the attacks and shared a = short-term, medium-term and long-term roadmap for mitigations of the = attacks. We believe this alone is sufficient supporting evidence. >=20 > We welcome any feedback.=20 >=20 > Chairs, if there is some time available and you feel it relevant, we = would like to request 5 minutes to present our formal analysis for = lake-ra draft. >=20 > Best regards, > Usama, Slava (Viacheslav), and Jean-Marie >=20 > PS: You don't need to keep me in To/CC. I am back on list ;) >=20 >=20 > On 11.01.26 02:58, Muhammad Usama Sardar wrote: >> Hi lakers, >>=20 >> Sending this separately to keep the two discussions separate. >>=20 >> We discovered relay attacks in intra-handshake attestation = implementations of attested TLS. Our intuition (no formal proof yet) is = that the attacks should apply to attested EDHOC protocol in = intra-handshake attestation [6] as well -- at least for the case of = Responder as Attester. >>=20 >> Welcome any questions/thoughts/opinions. >>=20 >> -Usama >>=20 >> PS: For any follow-up, please keep me explicitly in To/CC. >>=20 >>=20 >>=20 >> -------- Forwarded Message -------- >> Subject: [Ufmrg] Relay Attacks in Intra-handshake Attestation for = Confidential Agentic AI Systems >> Date: Sun, 11 Jan 2026 02:17:42 +0100 >> From: Muhammad Usama Sardar = = >> To: seat@ietf.org = , UFMRG IRTF = >>=20 >>=20 >>=20 >> Hi SEAT and UFMRG, >>=20 >> # Context >>=20 >> We (i.e., I, Dr. Viacheslav Dubeyko [IBM], and Prof. Jean-Marie = Jacquet [University of Namur]) did an extensive exploration of binding = mechanisms in intra-handshake attestation for confidential agentic AI = systems, that was presented on mic at SEAT meeting 124 and later = submitted as a draft [0] with focus on AI agent. In line with the scope = of SEAT charter, we also did formal analysis in state-of-the-art tool = ProVerif and we would like to share a summary of our findings from our = formal analysis with the hope that the analysis provides important data = points to WG for making informed decisions. >>=20 >> # Key Finding >>=20 >> All analyzed binding mechanisms and implementations are ad-hoc and = all of them result in relay attacks. >>=20 >> Please note that this includes Meta's AI [1] for which a thorough = security assessment [2] was carried out by Trail of Bits and they were = unable to capture the relay attacks but as kindly clarified by Tjaden = Hess, no formal methods were used in their review process. Our analysis = shows the value of formal methods in the review process. >>=20 >> # Fundamental Issue >>=20 >> Basically, there is no binding of Evidence to the TLS connection in = all of these implementations. >>=20 >> # TEE-agnostic System Model >> Layered Attester (e.g., Intel TDX) >> Composite Attester (e.g., Arm CCA) >> # Scope of Attested TLS >> Intra-handshake attestation >> # Formalization Approach >>=20 >> Symbolic security analysis >> # Formalization Tool >>=20 >> ProVerif >>=20 >> # Binding Mechanisms >>=20 >> A. We considered the following values for user-defined field "rdata" = in TEEs >> Client's TLS nonce >> Client's Attestation nonce >> Early exporter >> (Hash of) Server's public key >> Question for WG/RG: Is someone aware of any other value that folks = use in "rdata"? If possible, please share a link to specification and/or = implementation together. >>=20 >> B. Combinations: >> We considered the following combinations of binding mechanisms from = A: >> Hash (Client's TLS nonce || Server's public key) >> Hash (Client's Attestation nonce || Server's public key) >> Question for WG/RG: Is someone aware of any other combination that = folks use in "rdata"? If possible, please share a link to specification = and/or implementation together. >>=20 >>=20 >>=20 >> # Prominent Industrial Implementations >>=20 >> Edgeless Systems Contrast [3]: uses binding mechanism B.2 >> Cocos AI [4] >> CCC proof-of-concept [5]: Implementation of = draft-fossati-tls-attestation >> Meta=E2=80=99s AI [1]: uses binding mechanism A.1 >> Question for WG/RG: Is someone aware of any other intra-handshake = attestation implementation? If possible, please share a link to = specification and/or implementation together. >>=20 >>=20 >> # Binding Levels >> Shared DH secret (g^xy) >> Client's handshake traffic key (htsc) >> Client's application traffic key (atsc) >>=20 >> # Correlation Properties >> G1: Correlation of Evidence to Shared DH Secret >> G2: Correlation of Evidence to Client=E2=80=99s Handshake Traffic Key >> G3: Correlation of Evidence to Client=E2=80=99s Application Traffic = Key >>=20 >> # Results >>=20 >> We proved the proposition: G3 =3D> G2 =3D> G1 >>=20 >> We discovered relay attacks in all above proposals for binding = mechanisms as well as all implementations analyzed. We provide a formal = proof of insecurity that all above binding mechanisms and = implementations fail to even achieve G1 property (Level 1 binding). >>=20 >> Any binding that involves server's public key needs additional = assumption that server's private key does not leak. >>=20 >> In general, all solutions fail when server's private key is leaked. = In other words, extension of TLS with attestation in these = implementations is not really bringing much benefit from a security = perspective and rather giving a false sense of security. >>=20 >> We believe that it is not possible to achieve level 3 binding for = intra-handshake attestation within the scope of SEAT charter. >>=20 >>=20 >> # Implementation Issues >> Meta's AI uses client's TLS nonce (instead of attestation nonce), and = hence does not provide Evidence freshness. >> Cocos AI abuses the SNI extension to convey attestation nonce. >> Edgeless Systems Contrast was abusing the SNI extension to convey = attestation nonce, and currently abusing the ALPN extension to convey = attestation nonce. >>=20 >> # Proposed Mitigation >> We propose a cryptographic binder and modify CertificateVerify = message, which achieves level 2 binding. >>=20 >> # Paper and Artifacts >> A paper draft has been prepared and artifacts are well-documented. If = you are interested in reviewing one/both of them and can provide some = feedback until 19th Jan, please reach out to me off-list. If someone can = substantially improve the paper and/or artifacts, we are very welcoming = to adding you as co-author. We will make the paper and artifacts public = later on. >>=20 >>=20 >> # Contributors >> We thank Juho Fors=C3=A9n, Mariam Moustafa, Markus Rudy, Tjaden Hess, = Yuning Jiang, and Pavel Nikonorov for sharing their insights and = providing valuable feedback. >>=20 >>=20 >> # Other known related implementations >> Attested EDHOC: Our intuition (no formal proof yet) is that the = attacks should apply to attested EDHOC protocol in intra-handshake = attestation [6] as well -- at least for the case of Responder as = Attester. We will reach out to LAKE WG to inform them about these = attacks. >> Attested Noise: Confer's private inference [7] uses binding mechanism = A.4 [8] for Noise protocol. This implementation started just 3 weeks ago = (with holidays in between) and is not mature yet. Anyway, we will reach = out to the implementer (Moxie Marlinspike) to inform him about these = attacks. >>=20 >> # Feedback/Ideas >> We believe that we have explored all options in intra-handshake = attestation within the scope of SEAT charter. We look forward to your = thoughts and ideas on how we can mutually progress this work forward. >>=20 >> -Usama >>=20 >> [0] = https://datatracker.ietf.org/doc/draft-jiang-seat-dynamic-attestation/ >> [1] = https://ai.meta.com/static-resource/private-processing-technical-whitepape= r >>=20 >> [2] = https://github.com/trailofbits/publications/blob/master/reviews/2025-08-me= ta-whatsapp-privateprocessing-securityreview.pdf >>=20 >> [3] = https://github.com/CCC-Attestation/meetings/blob/main/materials/MarkusRudy= .contrast-atls-ccc-attestation.pdf >>=20 >> [4] https://docs.cocos.ultraviolet.rs/atls >> [5] https://github.com/ccc-attestation/attested-tls-poc >>=20 >> [6] https://datatracker.ietf.org/doc/draft-ietf-lake-ra/ >>=20 >> [7] https://confer.to/blog/2026/01/private-inference/ >>=20 >> [8] = https://github.com/ConferLabs/confer-proxy/blob/0f69f522f7597c6587741055e8= 6ae802c10891ab/src/main/java/org/moxie/confer/proxy/attestation/Attestatio= nService.java#L145 >>=20 > [9] = https://web.archive.org/web/20260227160554/https://www.ultraviolet.rs/blog= /tee-tls-privacy/ > --=20 > Lake mailing list -- lake@ietf.org > To unsubscribe send an email to lake-leave@ietf.org --Apple-Mail=_D9AA8AAB-266B-47B9-AF8C-59194120FA2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Usama,

Thanks for sharing, insightful. I added a = 5-minute slot to the agenda as I understand that it would relate to = EDHOC, not TLS.

Looking at the Relay Attack = Scenario and the corresponding figure in [9], I would like to confirm = with you that the Attacker maintains two separate sessions, one with the = Relying Party and the other with the Attester (Legitimate = Agent)?

I might be missing something from [9], = but I don=E2=80=99t quite understand the link between the three Bindings = Levels that you define and the actual mitigation of the attack. The = attack that is explained in Relay Attack Scenario in [9] seems to be = mitigated already with Binding Level 1 - shared DH secret. Is that = correct? If so, the detail that I do not understand is which attack(s) = are Level 2 and Level 3 bindings protecting = against?

Best,
Mali=C5=A1a

On Mar 3, 2026, at 19:01, = Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> = wrote:

=20 =20

Hi lakers,

Following up with supporting public evidence: Cocos AI has publicly acknowledged [9] the relay attacks last = Friday. 

# Context

As helpful context, Cocos AI [4] claimed their attested TLS = to be the "best in the world" in the Confidential Computing Consortium and despite we having informed them repeatedly about the attacks after our formal analysis, they were continuing to misguide the community on social media. Anyway, we now respect their honesty and transparency, and we remain fully committed to helping them towards secure solutions.

# Cocos AI acknowledgment of = attacks

Cocos AI (one of the implementers of the protocol) has = publicly acknowledged [9] our email and the relay attacks we highlighted on their design and implementation in our email. Particularly, see the sections "Limitations and the Relay Attack" and "The Relay Attack Scenario" in [9]. Note that their description is almost a paraphrase of our email. There are some nits that we disagree with them but that doesn't matter much. They have essentially acknowledged the attacks and shared a short-term, medium-term and long-term roadmap for mitigations of the attacks. We believe this alone is sufficient supporting evidence.

We welcome any = feedback. 

Chairs, if there is some time available and you = feel it relevant, we would like to request 5 minutes to present our formal analysis for lake-ra draft.

Best regards,
Usama, Slava (Viacheslav), and Jean-Marie

PS: You don't need to keep me in = To/CC. I am back on list ;)


On 11.01.26 02:58, Muhammad Usama Sardar wrote:

Hi lakers,

Sending this separately to keep the = two discussions separate.

We discovered relay attacks in intra-handshake attestation implementations of attested TLS. Our intuition (no formal proof yet) is that the attacks should apply to attested EDHOC protocol in intra-handshake attestation [6] as well -- at least for the case of Responder as Attester.

Welcome any = questions/thoughts/opinions.

-Usama

PS: For any follow-up, please keep me explicitly in = To/CC.



-------- Forwarded Message --------
Subject: [Ufmrg] Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems
Date: Sun, 11 Jan 2026 02:17:42 +0100
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
To: seat@ietf.org <seat@ietf.org>, UFMRG IRTF <ufmrg@irtf.org>




Hi SEAT and = UFMRG,

# Context

We (i.e., I, Dr. Viacheslav Dubeyko [IBM], and Prof. Jean-Marie Jacquet [University of Namur]) did an extensive exploration of binding mechanisms in intra-handshake attestation for confidential agentic AI systems, that was presented on mic at SEAT meeting 124 and later submitted as a draft [0] with focus on AI agent. In line with the scope of SEAT charter, we also did formal analysis in state-of-the-art tool ProVerif and we would like to share a summary of our findings from our formal analysis with the hope that the analysis provides important data points to WG for making informed decisions.

# Key = Finding

All analyzed binding mechanisms and implementations are ad-hoc and all of them result in relay attacks.

Please note that this includes = Meta's AI [1] for which a thorough security assessment [2] was carried out by = Trail of Bits and they were unable to capture the relay attacks but as kindly clarified by Tjaden Hess, no formal methods were used in their review process. Our analysis shows the value of formal methods in the review = process.

# Fundamental Issue

Basically, = there is no binding of Evidence to the TLS connection in all of these implementations.

# = TEE-agnostic System Model
  • Layered Attester (e.g., Intel TDX)
  • Composite Attester (e.g., Arm CCA)
# Scope of Attested TLS
  • Intra-handshake attestation

# Formalization Approach

  • Symbolic security analysis

# Formalization Tool

  • ProVerif

# Binding Mechanisms

A. We considered the following values for user-defined field "rdata" in TEEs
  1. Client's TLS nonce
  2. Client's Attestation nonce
  3. Early exporter
  4. (Hash of) Server's public key

Question for WG/RG: Is someone aware of any = other value that folks use in "rdata"? If possible, please share a link to specification and/or implementation = together.

B. Combinations:
We considered = the following combinations of binding mechanisms from = A:
  1. Hash (Client's TLS nonce || Server's public = key)
  2. Hash (Client's Attestation nonce || Server's public key)

Question for WG/RG: Is someone aware = of any other combination that folks use in "rdata"? If possible, please share a link to specification and/or implementation together.


# Prominent Industrial Implementations

  1. Edgeless Systems Contrast [3]: uses binding mechanism B.2
  2. Cocos AI [4]
  3. CCC proof-of-concept [5]: Implementation of draft-fossati-tls-attestation
  4. Meta=E2=80=99s AI [1]: uses binding mechanism = A.1
Question for WG/RG: Is someone aware of any other intra-handshake attestation implementation? If possible, please share a link to specification and/or implementation together.


# Binding Levels
  1. Shared DH secret (g^xy)
  2. Client's handshake traffic key (htsc)
  3. Client's application traffic key (atsc)

# = Correlation Properties
  • G1: Correlation of Evidence to Shared DH Secret
  • G2: Correlation of Evidence to Client=E2=80=99s = Handshake Traffic Key
  • G3: Correlation of Evidence to Client=E2=80=99s = Application Traffic Key

# = Results

We proved = the proposition: G3 =3D> G2 =3D> G1

We = discovered relay attacks in all above proposals for binding mechanisms as well as all implementations analyzed. We provide a formal proof of insecurity that all above binding mechanisms and implementations fail to even achieve G1 property (Level 1 binding).

Any binding = that involves server's public key needs additional assumption that server's private key does not leak.

In general, = all solutions fail when server's private key is leaked. In other words, extension of TLS with attestation in these implementations is not really bringing much benefit from a security perspective and rather giving a false sense of security.

We believe = that it is not possible to achieve level 3 binding for intra-handshake attestation within the scope of SEAT charter.


# = Implementation Issues
  • Meta's AI uses client's TLS nonce (instead of attestation nonce), and hence does not provide Evidence freshness.
  • Cocos AI abuses the SNI extension to convey attestation nonce.
  • Edgeless Systems Contrast was abusing the SNI extension to convey attestation nonce, and currently abusing the ALPN extension to convey attestation nonce.

# = Proposed Mitigation
  • We propose a cryptographic binder and modify CertificateVerify message, which achieves level 2 binding.

# Paper and Artifacts
A paper draft = has been prepared and artifacts are well-documented. If you are interested in reviewing one/both of them and can provide some feedback until 19th Jan, please reach out to me off-list. If someone can substantially improve the paper and/or artifacts, we are very welcoming to adding you as co-author. We will make the paper and artifacts public later on.


# = Contributors
We thank Juho Fors=C3=A9n, Mariam Moustafa, Markus Rudy, Tjaden Hess, = Yuning Jiang, and Pavel Nikonorov for sharing their insights and providing valuable feedback.


# Other = known related implementations
  • Attested EDHOC: Our intuition (no formal proof yet) is that the attacks should apply to attested EDHOC protocol in intra-handshake attestation [6] as well -- at least for the case of Responder as Attester. We will reach out to LAKE WG to inform them about these attacks.
  • Attested Noise: Confer's private inference [7] uses binding mechanism A.4 [8] for Noise protocol. This implementation started just 3 weeks ago (with holidays in between) and is not mature yet. Anyway, we will reach out to the implementer (Moxie Marlinspike) to inform him about these attacks.

# = Feedback/Ideas
We believe = that we have explored all options in intra-handshake attestation within the scope of SEAT charter. We look forward to your thoughts and ideas on how we can mutually progress this work forward.

-Usama

[0] https://datatracker.ietf.org/doc/draft-jiang-seat= -dynamic-attestation/

[1] https://ai.meta.com/static-resource/private-proce= ssing-technical-whitepaper

[2] https://github.com/trailofbits/publications/blob/= master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf<= /a>

[3] https://github.com/CCC-Attestation/meetings/blob/= main/materials/MarkusRudy.contrast-atls-ccc-attestation.pdf

[4] https://docs.cocos.ultraviolet.rs/atls

[5] = https://github.com/ccc-attestation/attested-tls-p= oc

[6] https://datatracker.ietf.org/doc/draft-ietf-lake-= ra/

[7] https://confer.to/blog/2026/01/private-inference/=

[8] https://github.com/ConferLabs/confer-proxy/blob/0= f69f522f7597c6587741055e86ae802c10891ab/src/main/java/org/moxie/confer/pro= xy/attestation/AttestationService.java#L145

[9] https://web.archive.org/web/20260227160554/http= s://www.ultraviolet.rs/blog/tee-tls-privacy/
--
Lake mailing list -- lake@ietf.org
To unsubscribe send an = email to = lake-leave@ietf.org

= --Apple-Mail=_D9AA8AAB-266B-47B9-AF8C-59194120FA2F--