Return-Path: X-Original-To: wimse@ietfa.amsl.com Delivered-To: wimse@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F9AC14F738 for ; Fri, 26 Jul 2024 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thesax-es.20230601.gappssmtp.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HccT2bXhm2CS for ; Fri, 26 Jul 2024 11:59:22 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2285C14F71F for ; Fri, 26 Jul 2024 11:59:21 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-75a6c290528so959241a12.1 for ; Fri, 26 Jul 2024 11:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thesax-es.20230601.gappssmtp.com; s=20230601; t=1722020361; x=1722625161; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7v2K6XOIn5MbeWRQOooHKI6BCHDvmG0iuhMUTynvYXo=; b=YqICfaUhhJSs2RVXqYG25iHAGZ06pZa7clPm0oNkstm3pKYJ6+U7HOx//7SZEeJnbp zINQJgtyayXCHfzodlZEgnEbgNpHtuGLwLKwQEhPoyMRFigm7F9+wuuhBFvvlgN72n1O Y/GBKFc32804uJj38oY8KjPo9nOd8NbD6rAGu0SwiiSON8waEVb7R/ioVjTXqgcd7Ktl 2tB7BKDke02LkP9ELDqHSz6ygcGWO9Rar25KTEwp3aBrPxJPS20971mZllMNx3fb1QX7 8gYlj29wAUx1fuJLnU8VQ0M8k1hRFfK9bWbxQJknDwypAVJ4FPu8o8kekbmzq2d7hgSW GESg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722020361; x=1722625161; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7v2K6XOIn5MbeWRQOooHKI6BCHDvmG0iuhMUTynvYXo=; b=R7o0NMrKMhYOxn/0NkdG9h9WAExdaQc0yIO30ZExj3rl4OrrxlQo9ODhJou0SpVdF+ ehy84U/A8K/Rl94yHL/MpDvrEOkKdkyqzCGpvVR4Tb0Zv7ARTqdS8HCjA3rX6i1DgVRA vfwtWGrpAoOgsA0V3/Y5UbyyCcoaQhvOUT9glsCCg+zZrvWFmj3zlE9YcPHKpL+4v815 w6w3jWjEpHJbvZNuEtHB2kl1iHjMEbOKySzWqv9duxVXVi2XxM+TYYUwkdfy1hwhrITi BFgpd1zYhgVVA5SeFnax0GYD0zhP2qcmvDsnaKd2vU7/PInXwn3tLjjkj04wE7Ib1v/N 1AEQ== X-Forwarded-Encrypted: i=1; AJvYcCXVhnLlx2rt8WHcJrYsEPB5uuaugEZl+NxfnHnVx54n7YSRTq3iN5yWtLuxzhp30osbLgAP6qWR5ytl1yio2A== X-Gm-Message-State: AOJu0YxGLQS2uyocz56r0sy9FOxlEXJcqXlK62DMrVznFMdM5cWms36H EvO12CS0LCvUUXw74ymXmZefwjiAAdYRQbVgc6fTGlNtgK+f/Lcnbs4yz/QfU238Y8+5e2CfPL/ tCJmCqteBqAkf1vZTkmwIe+2P4hUTXqK/1Eh4kvNuvvANqXVI X-Google-Smtp-Source: AGHT+IGmli+xyh5I0eH0WXLTEQjnYl2GLDlUU2UbNXTSZPyMQURhW7N/lRPiEY1P2HCT7n+U6sg5FasfwU4yEJ+keAc= X-Received: by 2002:a17:903:22c8:b0:1fc:6ebf:9092 with SMTP id d9443c01a7336-1ff04932a3emr6111035ad.57.1722020361092; Fri, 26 Jul 2024 11:59:21 -0700 (PDT) MIME-Version: 1.0 References: <9EFDE84B-77A9-4CB8-8E10-96D6305FD42A@amazon.com> <89478A9C-609B-4A7B-B310-382B9F3565D4@amazon.com> In-Reply-To: From: "Dean H. Saxe" Date: Fri, 26 Jul 2024 11:59:10 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary="000000000000eb60e0061e2b1bd2" Message-ID-Hash: 42KVB7AODF2IZ4MAZBSEKMCXLKIQNYDF X-Message-ID-Hash: 42KVB7AODF2IZ4MAZBSEKMCXLKIQNYDF X-MailFrom: dean@thesax.es X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "McAdams, Darin" , "wimse@ietf.org" , Watson Ladd X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BWimse=5D_Re=3A_Runtime_costs_of_multiple_signatures=3F?= List-Id: WIMSE Workload Identity in Multi-Service Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000eb60e0061e2b1bd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 dean@thesax.es On Fri, Jul 26, 2024 at 8:14=E2=80=AFAM Justin Richer wro= te: > 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, deco= de > 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 ne= ed > 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 > *Sent:* Friday, July 26, 2024 9:53 AM > *To:* McAdams, Darin > *Cc:* wimse@ietf.org ; Watson Ladd > *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-r= eqs/? > 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 redu= ce > the processing overhead down the call stack. > > Embedding may not be *exactly* what=E2=80=99s required, perhaps there=E2= =80=99s an > additional use case to consider that enables bundling or combining tokens= . > I=E2=80=99ll author a PR to add this use case. > > -dhs > -- > Dean H. Saxe > dean@thesax.es > > > > On Jul 25, 2024 at 5:49:44=E2=80=AFPM, "McAdams, Darin" 40amazon.com@dmarc.ietf.org> wrote: > > ECDSA 256 verification is a part of it. There=E2=80=99s also multiple inv= ocations > of a JSON parser to get at contents of the JWTs, and other overhead. > > On Jul 24, 2024, at 3:17=E2=80=AFPM, Watson Ladd = wrote: > > > =EF=BB=BFCAUTION: This email originated from outside of the organization.= Do not > click links or open attachments unless you can confirm the sender and kno= w > the content is safe. > > > > > > On Wed, Jul 24, 2024 at 2:35=E2=80=AFPM McAdams, Darin > > > wrote: > > > > > > I ran the numbers and we=E2=80=99re on the edge of what (I think) is ac= ceptable, > and on a slippery slope. > > > > > > Here=E2=80=99s 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=E2=80=99re 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=E2=80=99s the baseline. It would increase further with RAR, or addin= g richer > context to a Txn-Token, and so on. > > > > > > The reason I say it=E2=80=99s a slippery slope is because I=E2=80=99m o= bserving a > pattern where each WG solves it=E2=80=99s 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=E2=80=99s 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 -- wimse@ietf.org > To unsubscribe send an email to wimse-leave@ietf.org > > --000000000000eb60e0061e2b1bd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin,

Thank=C2=A0you=C2=A0for the rem= inder about token buckets, I had forgotten about this work as another optio= n to coalesce multiple tokens into a single structure.

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

-dhs
--
Dean H. Sax= e
dean@thesax.es=



On Fri, Jul 26, 2024 at 8:14=E2= =80=AFAM Justin Richer <jricher@mit.e= du> wrote:
Chair hat off, architect hat on.=C2=A0

Embedding a token into another token really just hides the problems mo= re 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 w= ith unwrapping the underlying pieces. Then it's decode, parse, validate, decode again, and so on.=C2=A0

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 struct= ure I hand wave at in https://datatracker.ie= tf.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 cryp= tographic capability that individual tokens don't, and it allows change= s (especially additive ones) without wrapping. Tokens have their place but when they start to multiply, I think we do nee= d to ask if it's the right structure.=C2=A0

- Justin=C2=A0
From: = Dean H. Saxe <dean@t= hesax.es>
Sent: Friday, July 26, 2024 9:53 AM
To: McAdams, Darin <darinm=3D40amazon.com@dmarc.ietf.org>
Cc: wimse@ietf.o= rg <wimse@ietf.o= rg>; Watson Ladd <watsonbladd@gmail.com>
Subject: [Wimse] Re: Runtime costs of multiple signatures?
=C2=A0
Darin,

I see this as a combination of the existing use cases in= =C2=A0https://datatracker.ietf.org/doc/dr= aft-rosomakho-wimse-tokentranslation-reqs/?=C2=A0 Specifically use cases 1, 2, and 4: token format change, token encoding change, and emb= edding one token in another.=C2=A0 The tokens would still have to be proces= sed at least once to make these transformations in order to reduce the proc= essing overhead down the call stack.

Embedding may not be exactly what=E2=80=99s require= d, perhaps there=E2=80=99s an additional use case to consider that enables = bundling or combining tokens.=C2=A0 I=E2=80=99ll author a PR to add this us= e case.

-dhs
--
Dean H. Saxe
dean@thesax.es



On Jul 25, 2024 at 5:49:44=E2=80=AFPM, "McAdams, Dari= n" <darinm=3D40amazon.com@dmarc.ietf.org> wrote:
ECDSA 256 verification is a part of it. There=E2=80=99s also multiple = invocations of a JSON parser to get at contents of the JWTs, and other over= head.

On Jul 24, 2024, at 3:17=E2=80=AFPM, Watson Ladd = <watsonbladd@= gmail.com> wrote:

=EF=BB=BFCAUTION: This email originated from outs= ide 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=E2=80=AFPM McAd= ams, Darin
> <darinm=3D40amazon.com@dmarc.ietf.org> wrote= :
>
> I ran the numbers and we=E2=80=99re on the e= dge of what (I think) is acceptable, and on a slippery slope.
>
> Here=E2=80=99s 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=E2=80=99r= e in the ballpark of ~2K bytes (25% of typical 8K header space), and approaching a millisecond in processing time for all the hashi= ng, signature verification, and JSON parsing. And, that=E2=80=99s the basel= ine. It would increase further with RAR, or adding richer context to a Txn-= Token, and so on.
>
> The reason I say it=E2=80=99s a slippery slo= pe is because I=E2=80=99m observing a pattern where each WG solves it=E2=80= =99s goals by adding 1-2 tokens to a request. Viewed independently, each de= cision 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=E2=80=99s criteria for evaluating so= lutions should include some reasonable goals on cumulative token sizes and processing time. This may lead us to conside= r more compact representations of tokens, or perhaps mechanisms to bundle m= ore 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 th= e 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 -- w= imse@ietf.org
To unsubscribe send an email to wimse-leave@ietf.org
--000000000000eb60e0061e2b1bd2--