denniswon

  ---
  zkTLS / TLSNotary Integration — Full Recall

  Project Summary

  Newton is integrating TLSNotary (MPC-TLS) for verifiable web data proofs in Rego policy evaluation. Author: @sigrid-magiclabs
  (Linear: NEWT-490).

  PR Chain Status (as of ~6 days ago)

denniswon

 ---
  Good context gathered. I can see the current flow is:

  1. newton-identity encrypts with RSA-OAEP (AWS KMS public key) → hex ciphertext
  2. Signs the encrypted string with EIP-712 (EncryptedIdentityData)
  3. Gateway verifies EIP-712 signature, then stores the encrypted data on-chain via submitIdentity
  4. At evaluation time, operators decrypt via AWS KMS

  The Newton SDK already has a full HPKE privacy module (X25519 + HKDF-SHA256 + ChaCha20-Poly1305) with AAD binding, Ed25519 signing, and
  uploadEncryptedData RPC.

denniswon

  Complete Triage: All 30 Findings

  Core Protocol — Actionable Fixes

  ┌─────┬─────────────────────────────────────────────────────────────────────┬───────────────┬─────────────────────────────────────────────────┐
  │  #  │                               Finding                               │    Verdict    │                     Action                      │
  ├─────┼─────────────────────────────────────────────────────────────────────┼───────────────┼─────────────────────────────────────────────────┤
  │ #4  │ IRegoVerifier calldata return type                                  │ Valid         │ Fix — change to memory in interface             │
  ├─────┼─────────────────────────────────────────────────────────────────────┼───────────────┼─────────────────────────────────────────────────┤
  │ #10 │ Missing TaskChallengedSuccessfully event in                         │ Valid         │ Fix — add event emission                        │

denniswon

Denial of Service: Failing External Calls in Challenge Slashing Operations

Executive Summary

The ChallengeVerifier contract's slashing mechanism can experience denial of service when processing challenges. The slashSigningOperators function iterates over all operators and strategies without any batching or gas limits, causing transactions to revert when these sets grow large. This prevents challenge finalization, attestation invalidation, and operator punishment.

Technical Analysis

Root Cause

denniswon

Denial of Service via Quadratic-Time Signer Verification in verifySigningOperatorsWhitelisted

Executive Summary

The verifySigningOperatorsWhitelisted function in OperatorVerifierLib.sol contains algorithmic complexity issues that can cause out-of-gas reverts when processing task responses on source chains. The function performs quadratic-time operations and numerous external calls that scale poorly with operator set size, enabling semi-trusted operators to induce denial-of-service conditions by manipulating the signer/non-signer ratio.

Vulnerability Details

Location

denniswon

Vulnerability Report: Repeatable Slashing in Direct-Challenge Functions

Executive Summary

The ChallengeVerifier contract contains two direct-challenge functions (challengeDirectlyVerifiedAttestation and challengeDirectlyVerifiedMismatch) that lack proper idempotency guards. This allows repeated invocations that trigger operator slashing multiple times for the same task, potentially draining all slashable stake from affected operators.

Vulnerability Details

Affected Functions

denniswon

Vulnerability Report: Missing taskCreatedBlock in Task Hash Enables Time Manipulation

Executive Summary

A critical vulnerability exists in the TaskLib.taskHash() function where the taskCreatedBlock field is not included in the computed hash. This allows attackers to manipulate time-sensitive security checks by supplying arbitrary taskCreatedBlock values that still pass task identity verification. The vulnerability enables two distinct attack vectors: premature slashing of operators on source chains and acceptance of late task responses.

Vulnerability Details

Location

denniswon

Vulnerability Report: Unprotected Reinitializer and Client Registration Squatting

Executive Summary

Two related access control vulnerabilities exist in the IdentityRegistry and PolicyClientRegistry contracts that enable attackers to disrupt or bypass the identity linking system:

IdentityRegistry.initializeV2() lacks access control, allowing any caller to replace the PolicyClientRegistry address
PolicyClientRegistry.registerClient() allows anyone to register any policy client and become its registry "owner"
These vulnerabilities can result in global denial-of-service for identity linking, bypass of client registration gating, or targeted per-client deactivation attacks.

denniswon

Vulnerability Report: Missing Ownership Verification in PolicyClientRegistry.registerClient

Executive Summary

The PolicyClientRegistry.registerClient function lacks verification that the caller is the actual owner of the policy client being registered. This allows any address to register as the "registry owner" of any INewtonPolicyClient contract, enabling them to control the client's active status and block identity linking operations in the dependent IdentityRegistry.

Vulnerability Details

Location

denniswon

Vulnerability Report: Non-Canonical EIP-712 Array Encoding in IdentityRegistry

Executive Summary

The IdentityRegistry contract contains a critical encoding flaw in its EIP-712 signature verification logic. The contract hashes bytes32[] arrays using abi.encode() instead of the canonical EIP-712 specification requiring abi.encodePacked(). This mismatch causes all standard EIP-712 signatures to fail verification, completely breaking the signature-based identity linking functionality.

Vulnerability Details

Location