[Wimse] Re: Runtime costs of multiple signatures?

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

Justin,

Thank you for the reminder about token buckets, I had forgotten about this
work as another option to coalesce multiple tokens into a single structure.

I'll pause on writing a PR while this conversation develops.

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



On Fri, Jul 26, 2024 at 8:14 AM Justin Richer <[e-mail]> wrote:

> Chair hat off, architect hat on.
>
> Embedding a token into another token really just hides the problems more
> than anything. We've seen this with deployments that wrap jwts into other
> jwts: the top layer might be quicker but now you've got to deal with
> unwrapping the underlying pieces. Then it's decode, parse, validate, decode
> again, and so on.
>
> Tokens, by their nature, are self contained, and I think our community
> jumps to them as a convenient data container too quickly. I do think
> there's room to consider other structures, like for example the graph
> structure I hand wave at in
> https://datatracker.ietf.org/doc/html/draft-richer-wimse-token-container-00
> - the contents of each bucket don't need to be tokens nor do they even need
> to be internally signed. The graph structure provides an overall
> cryptographic capability that individual tokens don't, and it allows
> changes (especially additive ones) without wrapping. Tokens have their
> place but when they start to multiply, I think we do need to ask if it's
> the right structure.
>
> - Justin
> ------------------------------
> *From:* Dean H. Saxe <[e-mail]>
> *Sent:* Friday, July 26, 2024 9:53 AM
> *To:* McAdams, Darin <darinm=[e-mail]>
> *Cc:* [e-mail] <[e-mail]>; Watson Ladd <[e-mail]>
> *Subject:* [Wimse] Re: Runtime costs of multiple signatures?
>
> 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]
>
>