search

private-attribution / ipa

A raw implementation of Interoperable Private Attribution
MIT License
42 stars 25 forks source link

[Sharding 1] TransportRestriction and Client #1348

Closed cberkhoff closed 1 month ago

cberkhoff commented 1 month ago

This is the first of a series of pull requests (PR) to enable sharding on IPA.

This change doesn't meaningfully change any tests or the operation of IPA. This is just adding abstractions that are going to be useful later.

The key introduction of this PR is the TransportRestriction trait. Please take a read at the included docs for more details. To make more sense of the intended usage of this new trait, I'm modifying MpcHelperClient to make use of it, but without altering it's API, yet. I understand the scope of this example is limited, hence I can answer questions about its future use if needed.

Renamed ClientIdentity::Helper to ClientIdentity::Header since I'm planning to use the same mechanism for Shard to Shard identity resolution.

codecov[bot] commented 1 month ago

Codecov Report

Attention: Patch coverage is 91.79104% with 11 lines in your changes missing coverage. Please review.

Project coverage is 93.48%. Comparing base (41b057c) to head (c3377eb). Report is 18 commits behind head on main.

Files with missing lines Patch % Lines
ipa-core/src/helpers/transport/mod.rs 94.54% 3 Missing :warning:
ipa-core/src/net/mod.rs 50.00% 3 Missing :warning:
ipa-core/src/sharding.rs 0.00% 3 Missing :warning:
ipa-core/src/bin/helper.rs 0.00% 1 Missing :warning:
ipa-core/src/net/client/mod.rs 98.14% 1 Missing :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #1348 +/- ## ========================================== - Coverage 93.49% 93.48% -0.02% ========================================== Files 211 210 -1 Lines 34959 35101 +142 ========================================== + Hits 32684 32813 +129 - Misses 2275 2288 +13 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

andyleiserson commented 1 month ago

The authentication requirements for shard communication are different than for helper-to-helper communication. Between helpers, it is important to prevent e.g. impersonation of H1 by H2. Between shards, that is not important. I would still want a secure connection with some kind of authentication (i.e., don't presume that shard-to-shard communication is over a trusted network). But the different shards are under the control of a single helper operator, so it's not important to prevent shard 2 from claiming to be shard 3.

Where I'm going with this is, we don't need to provision a unique certificate for each shard, if it saves work to not do so.

cberkhoff commented 1 month ago

Where I'm going with this is, we don't need to provision a unique certificate for each shard, if it saves work to not do so.

I'm planning to use the same certificate for both helper-to-helper and shard-to-shard. The certificate identifying the host regardless of the communication. Let me know what you think.