[Wimse] Re: Runtime costs of multiple signatures?

[Watson Ladd <[e-mail]>]

On Wed, Jul 24, 2024 at 2:35 PM McAdams, Darin
<darinm=[e-mail]> wrote:
>
> 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.

ECDSA 256 is 53 microseconds to verify on my mac according to openssl
speed. 4 of them is 212 microseconds. Where is the other 700
microseconds coming from to get to a millisecond/can we fix this by
using more compact formats?

Sincerely,
Watson



--
Astra mortemque praestare gradatim