[Wimse] Re: Runtime costs of multiple signatures?

["McAdams, Darin" <[e-mail]>]

I ran the numbers and we’re on the edge of what (I think) is acceptable, and on a slippery slope.

Here’s the stats. Consider 4 tokens that could become common in workloads: (1) access_token, (2) WIT token, (3) WPT Token, (4) Txn-Token. Based on the examples in the specs, we’re in the ballpark of ~2K bytes (25% of typical 8K header space), and approaching a millisecond in processing time for all the hashing, signature verification, and JSON parsing. And, that’s the baseline. It would increase further with RAR, or adding richer context to a Txn-Token, and so on.

The reason I say it’s a slippery slope is because I’m observing a pattern where each WG solves it’s goals by adding 1-2 tokens to a request. Viewed independently, each decision is logical. Cumulatively, it leads to a tragedy of the commons in terms of consuming the shared, finite space in HTTP headers.

Workloads are especially sensitive to these details due to the scale at which they operate. As a result, I would raise the question whether the working group’s criteria for evaluating solutions should include some reasonable goals on cumulative token sizes and processing time. This may lead us to consider more compact representations of tokens, or perhaps mechanisms to bundle more information under fewer signatures.

From: Yogi Porla <[e-mail]>
Date: Tuesday, July 23, 2024 at 9:00 AM
To: "McAdams, Darin" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [Wimse] Runtime costs of multiple signatures?

My thoughts and opinions Highlighted below
From: McAdams, Darin <[e-mail]>
Date: Monday, July 22, 2024 at 7:29 PM
To: [e-mail] <[e-mail]>
Subject: [Wimse] Runtime costs of multiple signatures?
Really appreciate all the work that the design teams have put into the WIMSE proposals.

I’ve been reading the docs in preparation for the IETF meeting and encountered a question I hadn’t seen discussed. The examples in service-to-service tokens<https://www.sheffer.org/wimse-s2s/draft-sheffer-wimse-s2s-protocol.html> appear to require a total of 3 or more tokens to be validated. This includes an OAuth access_token, the workload identity token, and the proof-of-possession token. The proliferation of tokens will have an impact on both the “bloat overhead” of each HTTP request, as well as the CPU and latency cost of running 3 or more asymmetric cryptographic operations. Perhaps it’s because I live in a world where a million requests per seconds is normal, but I found myself asking: “What will this cost?”. Has there been any discussion of the runtime costs of these proposals? It might be OK, or it might not, I simply don’t know and am curious.

Attached is a benchmark done by USP team who are working on the Attested Claims concept,slides 8 and 9 has benchmarks for 40 aggregations using schnorr concatenation and other schemes.Please note that this work is based on SPIRE and has some additional claims overhead for test purposes.


If this approach were pursued, audiences with efficiency concerns could raise additional questions such as: Is it acceptable to cache the validation results for a workload identity token so it’s not necessary to re-validate the same token on every HTTP request? Or, if a particular implementation has the means to do so, is it OK to distribute the token out of band so it’s not necessary to pass on every request?

Concept of TTLs for rotating certificates is used for SPIFFE workload identities , however, note that Revalidation isn’t performed by default when the certificate is issued ( note that there is a PR on SPIRE to force revalidation and this is being looked into) .   In-terms of Attested claims , given the nature of multiple workloads in transit ( User->  A-> B->C) and the potential of claims to change per request ( for instance a Claim at workload A could change based on the request), cached results may not be viable.

One other thing I noticed is that Figure 12<https://www.sheffer.org/wimse-s2s/draft-sheffer-wimse-s2s-protocol.html#name-signed-request> in the HTTP Message Signature example doesn’t include an Authorization header with a bearer-token, as in the DPoP variation. I wasn’t sure if that’s because it’s unnecessary when using HTTP Message Signatures, or if this was simply a mistake in the example. I was trying to wrap my head around the pros-and-cons of each option, and whether one requires fewer signatures.

-Darin