[Wimse] Re: Runtime costs of multiple signatures?

[Yaron Sheffer <[e-mail]>]

This discussion is interesting and important. However at this early point of the working group’s lifecycle, it also looks a lot like premature optimization.

 

And then speaking of optimization… Some of the work can be amortized in high performance environments. We’ve been discussing a way to replace some of the signatures by symmetric MACs, but again, I think it is too early to worry about that.

 

Darin, going back to your original message and the Authorization header: Yes, this is an inconsistency between Option 1 and Option 2, but it’s unimportant in that the Authorization header with a bearer token is optional anyway and is only there for backward compatibility with existing deployments. To further dive into this rabbit hole, see https://github.com/yaronf/wimse-s2s/issues/15" rel="nofollow">https://github.com/yaronf/wimse-s2s/issues/15

 

Thanks,

                Yaron

 

From: Dean H. Saxe <[e-mail]>
Date: Friday, 26 July 2024 at 11:59
To: Justin Richer <[e-mail]>
Cc: McAdams, Darin <darinm=[e-mail]>, [e-mail] <[e-mail]>, Watson Ladd <[e-mail]>
Subject: [Wimse] Re: Runtime costs of multiple signatures?

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" rel="nofollow">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/?" rel="nofollow">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]