DNSSEC-Provisioning / DNSSEC-Provisioning/music

DMS (Distributed multi-signer): Initial requirements.

Open
#223 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
6
Forks
5
PR merge metrics
No merged PRs in 30d

Description

- [x] The config must contain an MSIGNER name, defined under the YAML key music.sidecar.identity. Otherwise (for sidecar) fatal error.
- [x] The config should contain a cert for its MSIGNER target name. The CN for that cert must match the music.sidecar.identity name. Otherwise fatal error.
- [x] On start-up it sets up a "fake" micro zone on the sidecar.identity name. On that name a TLSA is published from the data in the cert.
- [ ] On start-up it should check for a published TLSA RR in the public namespace and compare that to the generated TLSA.
- [ ] If there is no TLSA, music-sidecar should print the TLSA in the log and to stdout together with a message that this RR mush be published.

When the MSIGNER RRset for a customer zone changes, a message is sent to the "MusicSyncEngine". It should then:
- [x] Identify the other sidecars (all but itself) and figure out if they are already known or not.
- [ ] For known sidecars, check whether this zone is already shared with them. If not, send a HEARTBEAT to them including the customer zone (i.e. add the zone to the set of zones shared with these other sidecars).
- [ ] For unknown sidecars, send an initial HELLO, also including the name of the zone, to initiate a heartbeat communication.

Sending HELLO messages:

- [ ] Look up the TLSA for the remote sidecar. Do DNSSEC validation. Store the validated TLSA in the Sidecar structure
- [ ] Create the HELLO message and sign it with our key. POST the message and examine the response data.

Receiving HELLO messages:

The problem with the initial HELLO is that we usually don't know the sender before hand. We don't want to go out and look up the TLSA, do DNSSEC validation, etc, before sending the response (as that would be opening up to various types of exhaustion attacks). So we will essentially just accept all HELLOs at face value, send a nice response and evaluate it later.

- [ ] Always send a nice response, regardless of whether we will use the HELLO or not.
- [ ] Check whether the number of individual remote signers is at MAX_SIDECARS or lower. If it is at max, log an error and return some sort of "already at max; sorry" response.
- [ ] Check whether the sender is known or not. If known check that the zone in the message is in the list of zones shared with this signer.
- [ ] If the sender is not known, check the zone to verify that this is a zone that we are aware of. If it is, add the sidecar to the map of remote sidecars.
- [ ] If the zone is not known (or the other sidecar is not in the MSIGNER RRset) then put the message in the queue for later re-evaluation.

Sending HEARTBEAT messages:

The assumption is that there will never be really large numbers of remote sidecars. Hence, we can send a heartbeat to each remote signer every time. The check for max allowed number of remote sidecars is checked on the initial HELLO.

- [ ] If the set of shared zones is less than heartbeat_chunk_size then list all of the zones in each heartbeat. If it is larger then use some method to work through the complete set over multiple HEARTBEATs.

Receiving HEARTBEAT messages:

- [ ] Check that the sender is a known remote sidecar. If not drop the message.
- [ ] Check that the zones listed in the message are zones that we are sharing with the remote sidecar. Any zone which is not must be logged as an error (but not fatal error).

Running the queue of messages for re-evaluation:

- [ ] If the zone and sidecar in a message doesn't match known zones and sidecars listed in the zone MSIGNER RRset within 24h, drop it from the queue (with a log message).

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.