[Wimse] Re: Runtime costs of multiple signatures?

[Yogi Porla <[e-mail]>]

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