Return-Path: X-Original-To: rats@mail2.ietf.org Delivered-To: rats@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6F18D13267164 for ; Mon, 31 Aug 2026 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788195597; bh=paS/sOSuqejG8cqMFKFGCTP3YSMmTUWUu9xqLGKDA4M=; h=From:Date:Subject:To; b=TDsIlF/eQQPAyLRZ8huf6nHIjDX6v8GUp8JJVf+y9k+OtwrICNAXtDULK8JSSfJA5 eeC1QfiM7aD1lfq9YUcecMrSXYZDajDyC0SA9Ori7FqEPQvN6VtF1L0YRGZPUyO8KC VPx/RmtgdjTT2hLriueydhYvHlfBRk4rNV9cy6/M= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=sangamdas-com.20251104.gappssmtp.com 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 OoIpmW5khlhJ for ; Mon, 31 Aug 2026 09:59:56 -0700 (PDT) Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 53C531326712D for ; Mon, 31 Aug 2026 09:59:56 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-836c8bde2dcso36746717b3.0 for ; Mon, 31 Aug 2026 09:59:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1788195595; cv=none; d=google.com; s=arc-20260327; b=cgZtVHmx/e1b1FBTuH/3ASIZ+21GIuGfF6uiqtC8reIdvmpnCCnnvdA3YcGHXOi0xY +/ihg5wX8NFQz8rPmG4mqZ83Z6Yj63quxvCLGVcJ/W6vKxb3ScA0hJeQiavc2CnQHS9k 5Xgq+wQ9P6MKY6ELAwhmlREfHoi72Lt8p5+rmKpu1zamJh96m7VUmUm0YafsPUXVEako MlZpn3+FXKAriZaRgQMdgDZxzOsCy3KNghjRbIRKXlB3f38B9gKBydiYbXIzlITT1sJi 5r2cmQmS6DbT8APR79uc4+eTWXYK3ul3JKuLJrXxCvK9adMnEo5gZvMcQHSmV9WEnnif 1KgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=1z0OhD4H3iD4ztDwSwXAvzKEAnqkNWIrqaDFFxvPxH0=; fh=QnncXh5Js8lSjNXKJeZij0rDGq8OM5k7dH31IzJ9QYw=; b=qB45pngxi/M+cURNks6Qu2B5uvR6vNVwWgCzTlhRocR3pdqQcWtn7wAWUdQAtX580K Pi+k2YEZrNUpnQhItEN5H2Mw1FNCSQFNSa83JYIRDmnkTw54UcGZZ9gwy5B9yDDZVsnh FnuurHUEBDHDnrlVBtOUUzhbMXAmUcXxNymuBxJJ16cqBVyh2PdZDljk30ZFSnrvxD7z +MZB3T+RtLrY0Tj3vUF3BDWvpw59oxZQcQV2QcYAvesesRCcELxdHDREgiysGfrvu/VB PXQptZy+BrQJHUtd3YRpkUYcSUiPg0gmkGbad1AJEr+e3+3hXdEuApaU3pdOt8wqzueu hkBg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sangamdas-com.20251104.gappssmtp.com; s=20251104; t=1788195595; x=1788800395; darn=ietf.org; h=content-type:to:subject:message-id:date:from:mime-version:from:to :cc:subject:date:message-id:reply-to:content-type; bh=1z0OhD4H3iD4ztDwSwXAvzKEAnqkNWIrqaDFFxvPxH0=; b=bIuLZ1ifb+/RqIkWoZp1gaKktuDi640igcz6GOXw00ENueuaKP3T03zRmBq8RKGbz4 ABcjvhBb0PszpDZFv5nhsPehmb1cpBl6K4KSv6/XX9w2EUpOZzAJFKVRvO8rE+qmP4YN N2SxoCaH8qlTWqCQHsTXA/Df/E55wKxZEu1BZ29RNnsA+7UrVjiFNrJU6Az8+Y9ZR9PF hwnhcP9+oqstYGk7jgt90Riw8P4TdIiApt2YWciH09brfMKRhKRjjV6PzItJEXakwE5Y nyZ8OcoCK+qRz8h+EqATcQTSeHX151L+SR42WiIoLgr4KuwiF+DfBRJH+smjsWZRFHwu eaOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788195595; x=1788800395; h=content-type:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1z0OhD4H3iD4ztDwSwXAvzKEAnqkNWIrqaDFFxvPxH0=; b=lSemJ9nl9jN4AxilaEcyGykRyl/pLt5N2nWJBLX8PhK/yPYZj7mzRJumPEGICHOTEa rF+J2Z+5cRFrMr0f58INJY7U3gn0qtlwIYSC5KjLBSfRAzVCLLpvp62l1QqwJpiApjmR 0LiNdxjUY7eAYBDEJwnPPGolC5wUKSSyUWSKr6rRgXQ5DJjTrqXgLr54JECQBjF6wLxE PK64VT6F6yD5dExDEzXmlGT2P1mNVTcnVOxyo3ERadZEgOcjz4+w5T1xMY1MerHkxSbM kZFj+1l/dCd9fbg9I7S79dAWCSlN8tCHsZQ1gFcUUqqLoJVtlUHGQTJqQgmlzr+NnfFA h50w== X-Gm-Message-State: AFuF++mqFpWcFa34Wx/iT+JVNfbyCj4MXeZqzgtP0pXpjunNWDF4QAyL emhxb9KzWvo6JNMfkTjfmy1h5kuhgVmEEAIyOQoT1TJxufz3MsiItMfE1hWJvmFgSd/z+WQ2Aw5 V7C+XymRoBMa2uVkiIevMChNlyIbVH+T14biJxMcn9EO2ZayYvqvirPJX X-Gm-Gg: AYBFou3ETNkle9if7/sjuBRqBAsry6WnfXVQ82ftimhuuB9npICj0iKnjpgIKQIjCss 4UBRjg9jctzbDU/yz75tjvwYmr4kwC8GrPlu/cFp0DN8KezygnPfQW98bVIfHLwdtW7MjoIAUCD ZT4vL8xAqRUBc/vPD1ng7J8tjG3mRVKQc76q4hysf1+/tBNChqf2fILhfH/4JgeLgt0OKL4zDph 4PUiV3Vg9r/LCAe8NbMt257twnRr1qnVzB16MRfm1A68PWdXtmOwXRd0j71ROQ2uxQEfzJ6X0kt rV1z+V3ojcEu5UtpkXzrtLH8Muxfnupp+Y7A1wIR7uPs8fGbUyIZpBVi2bJNro2w4SVnWgugXyj UCQ== X-Received: by 2002:a05:690c:dd3:b0:856:32d2:978c with SMTP id 00721157ae682-85d6c5027acmr110622767b3.23.1788195595381; Mon, 31 Aug 2026 09:59:55 -0700 (PDT) MIME-Version: 1.0 From: Sangam Das Date: Mon, 31 Aug 2026 22:29:44 +0530 X-Gm-Features: AcwNN1WjNQ_o4I3mLLmHLVYVcwap5WzhIzBrbv2b0njpSZQd7EXIx6cBhyMYEbc Message-ID: To: rats@ietf.org Content-Type: multipart/alternative; boundary="000000000000407e44065a5abb22" Message-ID-Hash: BZULPRX6PGLIRBKKTOELTWNDGMLMHJOU X-Message-ID-Hash: BZULPRX6PGLIRBKKTOELTWNDGMLMHJOU X-MailFrom: info@sangamdas.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rats.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BRats=5D_draft-das-rats-frontier-model-extraction-02_=E2=80=94_r?= =?utf-8?q?elease_control_after_attestation?= List-Id: Remote ATtestation procedureS Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000407e44065a5abb22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: draft-das-rats-frontier-model-extraction-02 =E2=80=94 release cont= rol after attestation; is there a RATS work item? Hello Team RATS, I have posted an individual Informational draft and am looking for guidance on whether any part of it belongs in RATS, and if so what the unit of work would be: https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/ This is not a DISPATCH/ART request and not a 3GPP or accelerator-ISA proposal. I am asking only about attestation and appraisal semantics. Problem ------- RATS can establish that a confidential CPU/GPU or workload is in an expected state (RFC 9334, EAT, device-assignment and cGPU EAR profiles). AIR and AEP-style work can record that an inference or action occurred. A later question remains: The environment is attested and the model has computed a result. May this specific sensitive model artifact leave the protected domain now? Examples of artifacts more sensitive than ordinary completion text: logits, full log-prob distributions, embeddings, hidden states, KV-cache material, diagnostic traces. Authentication and platform attestation do not, by themselves, answer that per-release question. A missing AIR receipt also does not stop the result from already having been returned. One worked case --------------- Participants: M model owner / relying party P evaluation partner (authenticated) W attested serving workload on a confidential GPU V RATS Verifier S release boundary (logical Finality Sink: API egress, DMA, or device egress =E2=80=94 placement is implementation, not RATS) Order and inputs: 1. M provisions W: model identity, policy "P may receive at most 100 high-resolution log-prob responses", extraction-state object, security epoch. Slow path may include platform attestation of W. 2. V appraises Evidence that W claims release-control is enabled, extraction state is rollback-resistant, and the expected sink class is active. V issues Attestation Results to M. Input: Evidence. Output: AR. This step does not release SMI. 3. P sends privileged query n (n =E2=89=A4 100). Input: partner identity, model, output class=3Dlogprobs. 4. W computes the log-probs inside the protected domain. Result is a Candidate Release: not yet returned to P. 5. W checks current extraction state, epoch, destination, output class, and remaining quota. If allowed, it atomically consumes one unit (e.g. 99 =E2=86=92 100) and only then lets S emit the artifact. 6. Query 101: computation may still occur. No release authority. S does not emit. Ordinary completion text, if separately permitted, is out of scope of this quota. 7. Snapshot rollback of host software that reports "only 20 used" does not restore quota if extraction state is outside that rollback domain. 8. Replay of the authority for release 100 is denied. What I am not asking RATS to standardize ---------------------------------------- GPU microarchitecture, HBM/DMA controllers, model formats, or a new inference protocol. Those stay with vendors / other SDOs. The RATS-shaped slice, if any, is a machine-appraisable statement that the attested environment implements a named release-control profile (enabled, policy/epoch, rollback-protected extraction state, sink class, alternate-egress claim) so a Relying Party can tell: "the accelerator is authentic" from "the accelerator is authentic and claims to enforce the expected protected release mechanism before SMI crosses the boundary." The act-specific release decision stays local and is not an EAT. Relation to current drafts -------------------------- TDX/cGPU EAR =E2=80=94 environment at session start; not per-release. AIR =E2=80=94 receipt after inference; missing receipt does not prevent return of the result. AEP =E2=80=94 evidence that an action occurred under claimed authority; not a fail-closed release gate. Epoch markers =E2=80=94 possible freshness input; not extraction quota. The draft treats those as complementary, not as replacements. Questions for the WG -------------------- 1. Is pre-effectuation release of sensitive model artifacts in scope for RATS, or is it only local TEE/serving policy plus ordinary attestation of the platform? 2. If any interoperable work is useful, should it be (a) Informational architecture only, (b) an EAT/EAR profile of release-control *capability and state* claims (illustrative names are in the draft; no IANA request in -02), (c) reuse of existing EAT measured-component / epoch-markers with no new profile, (d) none of the above? 3. Does the WG see a remaining gap versus AIR and AEP, or is "check policy then return logits" already covered? 4. If (b), should that profile live in RATS, or only as vendor Evidence that Verifiers already know how to ignore? I welcome the conclusion that existing mechanisms suffice. Relevant IPR will be disclosed per BCP 79. Draft: https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/ Sangam Das --000000000000407e44065a5abb22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Subject: draft-das-rats-front= ier-model-extraction-02 =E2=80=94 release control
after attestation; is there a RATS work item?

Hello Team RATS,

I have posted an ind= ividual Informational draft and am looking for=C2=A0guidance on whether any= part of it belongs in RATS, and if so what=C2=A0the unit of work would be:=

https://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extract= ion/

Thi= s is not a DISPATCH/ART request and not a 3GPP or accelerator-ISA
proposal. I am asking only about attestation and app= raisal semantics.

Problem
-------
RATS can establish that a confidential CPU/GPU or workload is in a= n=C2=A0expected state (RFC 9334, EAT, device-assignment and cGPU EAR=C2=A0p= rofiles). AIR and AEP-style work can record that an inference or
action occurred.

A later question remains:

The environment is attested and= the model has computed a result.
May this= specific sensitive model artifact leave the protected
domain now?

Examples of artifacts more sensitive than ordinary completion = text:
logits, full log-prob distributions, e= mbeddings, hidden states,
KV-cache material,= diagnostic traces.

Authentication and platform attestation do not, by themselves,
answer that per-release question. A missing AIR = receipt also does
not stop the result from a= lready having been returned.

One worked case
-----------= ----
Participants:
M model owner / relying party
P = evaluation partner (authenticated)
W atte= sted serving workload on a confidential GPU
= V RATS Verifier
S release boundary (lo= gical Finality Sink: API egress, DMA,
o= r device egress =E2=80=94 placement is implementation, not RATS)

Order and inputs:
1. M provision= s W: model identity, policy "P may receive at most
100 high-resolution log-prob responses", extraction-sta= te object,
security epoch.
Slow path may include platform attestation of W.

2. V appraises Evi= dence that W claims release-control is enabled,
extraction state is rollback-resistant, and the expected sink
class is active. V issues Attestation Results t= o M.
Input: Evidence. Output: AR. This st= ep does not release SMI.

3. P sends privileged query n (n =E2=89=A4 100).
Input: partner identity, model, output class=3Dlogprob= s.

4. W comp= utes the log-probs inside the protected domain.
Result is a Candidate Release: not yet returned to P.

5. W checks current extrac= tion state, epoch, destination, output
cl= ass, and remaining quota. If allowed, it atomically consumes
one unit (e.g. 99 =E2=86=92 100) and only then lets S e= mit the artifact.

6. Query 101: computation may still occur. No release authority.
S does not emit. Ordinary completion text, if= separately
permitted, is out of scope of= this quota.

7. Snapshot rollback of host software that reports "only 20 used"= ;
does not restore quota if extraction st= ate is outside that
rollback domain.

8. Replay of the= authority for release 100 is denied.

What I am not asking RATS to standardize
----------------------------------------
GPU microarchitecture, HBM/DMA controllers, model forma= ts, or a
new inference protocol. Those stay = with vendors / other SDOs.

The RATS-shaped slice, if any, is a machine-appraisable stat= ement
that the attested environment implemen= ts a named release-control
profile (enabled,= policy/epoch, rollback-protected extraction
state, sink class, alternate-egress claim) so a Relying Party can
tell:

"the accelerator is authentic"
from
"the accelerator= is authentic and claims to enforce the expected
protected release mechanism before SMI crosses the boundary."<= br style=3D"font-size:inherit">
The act-spec= ific release decision stays local and is not an EAT.

Relation to current drafts
--------------------------
TDX/cGPU EAR =E2=80=94 environment at session start; not per-rele= ase.
AIR =E2=80=94 receipt after= inference; missing receipt does
= not prevent return of the result.
A= EP =E2=80=94 evidence that an action occurred under claimed
authority; not a fail-closed re= lease gate.
Epoch markers =E2=80=94 possib= le freshness input; not extraction quota.
The draft treats those as complementary, not = as replacements.

Questions for the WG
------------------= --
1. Is pre-effectuation release of sensiti= ve model artifacts in
scope for RATS, or = is it only local TEE/serving policy plus
= ordinary attestation of the platform?

2. If any interoperable work is useful, should it= be
(a) Informational architecture only,<= br style=3D"font-size:inherit"> (b) an EAT/EAR profile of release-control= *capability and
state* claims (illus= trative names are in the draft; no
IA= NA request in -02),
(c) reuse of existing= EAT measured-component / epoch-markers
= with no new profile,
(d) none of the a= bove?

3. Doe= s the WG see a remaining gap versus AIR and AEP, or is
"check policy then return logits" already covered?<= br style=3D"font-size:inherit">
4. If (b), s= hould that profile live in RATS, or only as vendor
Evidence that Verifiers already know how to ignore?

I welcome the conclusion = that existing mechanisms suffice.
Relevant I= PR will be disclosed per BCP 79.

Draft:
ht= tps://datatracker.ietf.org/doc/draft-das-rats-frontier-model-extraction/

Sangam Das=
--000000000000407e44065a5abb22--