[Wimse] Re: Runtime costs of multiple signatures?

["Dean H. Saxe" <[e-mail]>]

 Darin,

I see this as a combination of the existing use cases in
https://datatracker.ietf.org/doc/draft-rosomakho-wimse-tokentranslation-reqs/?
Specifically use cases 1, 2, and 4: token format change, token encoding
change, and embedding one token in another.  The tokens would still have to
be processed at least once to make these transformations in order to reduce
the processing overhead down the call stack.

Embedding may not be *exactly* what’s required, perhaps there’s an
additional use case to consider that enables bundling or combining tokens.
I’ll author a PR to add this use case.

-dhs
--
Dean H. Saxe
[e-mail]



On Jul 25, 2024 at 5:49:44 PM, "McAdams, Darin" <darinm=
[e-mail]> wrote:

> 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
>
> --
> Wimse mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>