Hi Ruslan, We just had a meeting today to discuss this. We probably want to understand your use case better.
ALTS is a whole package: key exchange, record protocol, key management, and trust model. It seems strange to have non-ALTS handshake, but use ALTS record protocol. On the other hand, we are interested in developing gRPC SSL stack using handshaker service model. 1. gRPC code that talks to SSL handshaker service. This will have shared code with gRPC ALTS stack. 2. Handshaker service that conducts TLS 1.2 and/or 1.3 handshake. 3. Zero-copy frame protector that implement TLS record protocol. This will not use OpenSSL BIO API, instead, will directly call OpenSSL/BoringSSL AEAD crypto API. We probably have limit bandwidth on implementation. You probably can implement item 2. whereas we can implement item 1 first. Feel free to schedule a video conference with us. Thanks, Jiangtao On Thu, Apr 19, 2018 at 4:23 PM 'Ruslan Nigmatullin' via grpc.io < [email protected]> wrote: > Thanks for you response, > > Please let us know if we (Dropbox) can help in any way with this decision > or with implementing any functionality/tests for alts to ease the process. > > On Friday, March 30, 2018 at 4:51:43 PM UTC-7, [email protected] wrote: >> >> So far ALTS is for GCP use only. Let me discuss with my management to see >> whether we can provide an easy interface to use "pluggable" handshaker >> service. If so, we may expose API to choose either google default >> handshaker service or pluggable handshaker service. Google default >> handshaker service will check GCP environment and hardcode google metadata >> server address, whereas pluggable handshaker service can run on any >> platforms and use any handshaker service address. >> >> As for local identity, it is not set in gRPC stack currently. We could >> set through credential options. Again, this is related to whether we want >> to open up pluggable handshaker service. >> >> >> On Friday, March 30, 2018 at 12:30:35 PM UTC-7, Ruslan Nigmatullin wrote: >>> >>> >>> Hi Jiangtao, >>> >>> On Thursday, March 29, 2018 at 10:54:22 AM UTC-7, [email protected] >>> wrote: >>>> >>>> Hi Ruslan, >>>> >>>> ALTS is not ready for public consumption yet. We could expose ALTS to >>>> early access customers. >>>> >>> >>> Thanks for clarifying, we don't have immediate plans to use ALTS in our >>> production setup but we're evaluating if it is an option in mid/long term. >>> >>> >>>> Note that at this point, ALTS is for use inside GCP, such as >>>> authentication between two workloads running on GCP or for faster access of >>>> Google cloud services on GCP. >>>> >>>> So far we do not support ALTS outside GCP. Of course, you can write >>>> your own handshaker service and plug in whatever handshake protocol you >>>> want, see handshaker proto ( >>>> https://github.com/grpc/grpc-java/blob/master/alts/src/main/proto/handshaker.proto), >>>> and use ALTS gRPC code for record protocol. >>>> >>> >>> Thanks, this was a direction I was looking into due to the following >>> points: >>> 1. All handshaking logic is kept in single binary, few examples: >>> monitoring, rate limiting, cert rotation, session tickets, etc >>> 2. Implementation of ALTS record protocol is ~2x more efficient than >>> tls-based implementations (e.g. boringssl-based grpc-core), both for cpu >>> and memory >>> >>> Though it looks like that at least some implementations deny ability to >>> use ALTS outside of GCP environment (e.g. grpc-go one [1], ability to >>> disable was removed by [2]). >>> Are you comfortable with us (re)adding an ability to explicitly disable >>> this check from code? >>> >>> We may also need to expose an ability to specify local identity (it's >>> already part of HandshakerService API, so it's only grpc library change), >>> is it okay? >>> >>> >>>> Let us know if you are interested in using ALTS on GCP, so that we may >>>> give you early access. >>>> >>>> >>> 1. >>> https://github.com/grpc/grpc-go/blob/master/credentials/alts/alts.go#L136 >>> 2. https://github.com/grpc/grpc-go/pull/1931 >>> >>>> On Tuesday, March 27, 2018 at 11:49:34 AM UTC-7, Ruslan Nigmatullin >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> We're evaluating the possibility of using ALTS instead of TLS in our >>>>> internal infrastructure for visibility and performance reasons. >>>>> >>>>> How ALTS support is positioned from gRPC perspective? Is it GCP >>>>> implementation detail or you're supporting other companies in using it? >>>>> >>>>> We may need to expose extra API for configuring credentials (e.g. >>>>> specifying local identity significantly simplifies migration process and >>>>> it's already exposed in handshake api). Are you comfortable with it? >>>>> >>>>> Thanks, >>>>> Ruslan >>>>> >>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/grpc-io/FRiBpXucIRk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/8817d1c8-475e-47f1-ab15-951f764a3975%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/8817d1c8-475e-47f1-ab15-951f764a3975%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CACcm8_gEhS3giOgwTAotxXTGXJgaoQEkSvdenuTkizvEps9ynQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
