Hi Sumit,

Thanks for reviewing this. Regarding your query:
1. Impact on existing/old clients: the block token is just a plain byte
array from the client's perspective. It's up to OM's and Datanode's logic
to create, serialize, deserialize and verify the token. This change is
compatible with older client versions.
2. Each generated SecretKey is packaged with the algorithm name and other
auditing data before getting stored and distributed over the network. OM
and Datanodes only rely on the algorithm packaged with the SecretKey to
sign/verify tokens. A change in the configured algorithm doesn't impact the
keys that are already generated.

Thanks,
Duong


On Sun, May 21, 2023 at 9:20 PM Sumit Agrawal
<sumitagra...@cloudera.com.invalid> wrote:

> Hi Duong,
>
> Thanks for working on this. I have gone to design docs and it looks good.
>
> Few query:
> 1. Upgrade from existing block token with async algo to symmetric
> algorithm:
> - any impact to existing/old clients?
>
> 2. When using block token configuration with HMACWithSha256 and later
> changed to HMACWithSha1, and restart SCM to take config in effect.
> - do this have any impact to existing token and DNs running with old and
> new token?
> Just to know if algorithm is upgraded in system, how do this have impact or
> do need any further changes to support this.
>
>
> Regards
> Sumit
>
> On Sat, May 20, 2023 at 5:35 AM Duong Nguyen <du...@apache.org> wrote:
>
> > Dear Ozone Devs,
> >
> > I would like to start this discussion thread for the proposal to merge
> > HDDS-7733-Symmetric-Tokens to master.
> >
> > This feature branch contains the implementation to replace the costly
> token
> > signature generation using asymmetric (RSA) keys with symmetric key
> > algorithms, like HMAC with SHA256. Symmetric key algorithms bring a
> > much better performance and are the natural fit for Ozone token use case.
> > Yet, they require building a mechanism to generate, store, distribute,
> and
> > renew symmetric secret keys. That requirement is not trivial and has to
> be
> > split into smaller tasks that cannot be shipped individually. That is
> > the reason why the implementation of HDDS-7733
> > <https://issues.apache.org/jira/browse/HDDS-7733> happens in a separate
> > feature branch.
> >
> > HDDS-7733 is not a new feature but an internal redesign for Ozone tokens
> to
> > improve OM performance/Ozone scalability. Apart from the existing
> > integration and acceptance tests which should already cover the usage of
> > tokens pretty well, we also added E2E test cases to cover the edge cases
> > related to the symmetric secret keys life-cycle, as per HDDS-8003
> > <https://issues.apache.org/jira/browse/HDDS-8003>.
> >
> > More information can be found on the wiki page:
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255070328
> >
> > If there are no objections to the merge, we could start the official
> vote.
> >
> > Thanks,
> > Duong
> >
>
>
> --
> *Sumit Agrawal* | Senior Staff Engineer
> cloudera.com <https://www.cloudera.com>
> [image: Cloudera] <https://www.cloudera.com/>
> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image:
> Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera
> on LinkedIn] <https://www.linkedin.com/company/cloudera>
> ------------------------------
>

Reply via email to