[Wimse] Re: Runtime costs of multiple signatures?

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

ECDSA 256 verification is a part of it. There’s also multiple invocations of a JSON parser to get at contents of the JWTs, and other overhead.

> On Jul 24, 2024, at 3:17 PM, Watson Ladd <[e-mail]> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
>> 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