[Wimse] Re: Runtime costs of multiple signatures?

[Dmitry Izumskiy <[e-mail]>]

In context of this conversation I would like to refer to Donald Knuth - "We
should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil. Yet we should not pass up
our opportunities in that critical 3%"
On the current stage of our work I am not convinced that hashing,
signature verification and JSON parsing are in critical 3%.

My expectation is that first working prototypes of WIP, WPT or HTTP
signature will flush out all critical performance issues. Overall
accounting on the tendency that compute is getting cheaper over time,
focusing on security properties over performance for
architectural tradeoffs can be the right strategy. History of HTTPS/TLS
adoption already proved that.

Best regards,
Dmitry



On Mon, Jul 29, 2024 at 2:58 PM Brian Campbell <bcampbell=
[e-mail]> wrote:

> As an individual and contributor to the WIMSE Service to Service
> Authentication draft - the intention from my perspective of the s2s
> document is that there will be two things for service authentication, 1)
> the WIT and 2) either a WPT or HTTP signature. And there'd be one more
> thing (maybe a transaction token, the "original" oauth token, an "internal"
> oauth token, or something along those lines but only one such thing) that
> conveys context like the user identity and authorization situation of the
> larger request context. I do believe there are efficiency concerns here but
> hope that the slope isn't that slippery.
>
> On Wed, Jul 24, 2024 at 3: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.
>>
>>
>>
>> *From: *Yogi Porla <[e-mail]>
>> *Date: *Tuesday, July 23, 2024 at 9:00 AM
>> *To: *"McAdams, Darin" <[e-mail]>, "[e-mail]" <
>> [e-mail]>
>> *Subject: *RE: [Wimse] Runtime costs of multiple signatures?
>>
>>
>>
>> My thoughts and opinions Highlighted below
>>
>> *From: *McAdams, Darin <[e-mail]>
>> *Date: *Monday, July 22, 2024 at 7:29 PM
>> *To: *[e-mail] <[e-mail]>
>> *Subject: *[Wimse] Runtime costs of multiple signatures?
>>
>> Really appreciate all the work that the design teams have put into the
>> WIMSE proposals.
>>
>> I’ve been reading the docs in preparation for the IETF meeting and
>> encountered a question I hadn’t seen discussed. The examples in service-to-service
>> tokens
>> <https://www.sheffer.org/wimse-s2s/draft-sheffer-wimse-s2s-protocol.html>
>> appear to require a total of 3 or more tokens to be validated. This
>> includes an OAuth access_token, the workload identity token, and the
>> proof-of-possession token. The proliferation of tokens will have an impact
>> on both the “bloat overhead” of each HTTP request, as well as the CPU and
>> latency cost of running 3 or more asymmetric cryptographic operations.
>> Perhaps it’s because I live in a world where a million requests per seconds
>> is normal, but I found myself asking: “What will this cost?”. Has there
>> been any discussion of the runtime costs of these proposals? It might be
>> OK, or it might not, I simply don’t know and am curious.
>>
>>
>>
>> Attached is a benchmark done by USP team who are working on the Attested
>> Claims concept,slides 8 and 9 has benchmarks for 40 aggregations using
>> schnorr concatenation and other schemes.Please note that this work is based
>> on SPIRE and has some additional claims overhead for test purposes.
>>
>>
>>
>> If this approach were pursued, audiences with efficiency concerns could
>> raise additional questions such as: Is it acceptable to cache the
>> validation results for a workload identity token so it’s not necessary to
>> re-validate the same token on every HTTP request? Or, if a particular
>> implementation has the means to do so, is it OK to distribute the token out
>> of band so it’s not necessary to pass on every request?
>>
>>
>>
>> Concept of TTLs for rotating certificates is used for SPIFFE workload
>> identities , however, note that Revalidation isn’t performed by default
>> when the certificate is issued ( note that there is a PR on SPIRE to force
>> revalidation and this is being looked into) .   In-terms of Attested claims
>> , given the nature of multiple workloads in transit ( User->  A-> B->C) and
>> the potential of claims to change per request ( for instance a Claim at
>> workload A could change based on the request), cached results may not be
>> viable.
>>
>> One other thing I noticed is that Figure 12
>> <https://www.sheffer.org/wimse-s2s/draft-sheffer-wimse-s2s-protocol.html#name-signed-request>
>> in the HTTP Message Signature example doesn’t include an Authorization
>> header with a bearer-token, as in the DPoP variation. I wasn’t sure if
>> that’s because it’s unnecessary when using HTTP Message Signatures, or if
>> this was simply a mistake in the example. I was trying to wrap my head
>> around the pros-and-cons of each option, and whether one requires fewer
>> signatures.
>>
>> -Darin
>> --
>> Wimse mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*--
> Wimse mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>