Skip to content

Conversation

@ionut-arm
Copy link
Contributor

@ionut-arm ionut-arm commented Jan 27, 2026

Partly addresses #54

Signed-off-by: Ionut Mihalcea <[email protected]>
@ionut-arm ionut-arm force-pushed the security-considerations branch from 5055153 to 0e67d4c Compare January 27, 2026 12:50
@ionut-arm
Copy link
Contributor Author

cc @junzhanghw

@junzhanghw
Copy link

seems good.

Copy link
Collaborator

@thomas-fossati thomas-fossati left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ionut-arm for contributing this (and @junzhanghw for seeding some of the contents)!

I have left a few comments inline.

Comment on lines 414 to 417
Some Epoch Marker types require receiver state to detect replay/rollback or establish sequencing.
For epoch-tick-list, freshness requires receiver-side state to identify the “next unused” tick; deployments SHOULD define how missing/out-of-order ticks are handled and how resynchronization occurs.
For strictly-monotonic-counter, receivers must track the highest accepted counter to detect rollback.
Deployments SHOULD document whether they use global epoch tracking or per-Attester state and, if necessary, the associated window.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that if there are any functional considerations associated with a specific epoch marker, they should be documented alongside the epoch marker instance, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, I guess this is leaning more into the practicality of things. What do you think? Is something like this needed somewhere along the marker designs?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think? Is something like this needed somewhere along the marker designs?

At first glance, that’d be my preference.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved the section and integrated it into the main text, let me know how you find it.

ionut-arm and others added 6 commits January 27, 2026 15:43
Co-authored-by: Thomas Fossati <[email protected]>
Signed-off-by: Ionut Mihalcea <[email protected]>
Signed-off-by: Ionut Mihalcea <[email protected]>
Signed-off-by: Ionut Mihalcea <[email protected]>
Considerations in that section are more fundamental than seccons.

Signed-off-by: Ionut Mihalcea <[email protected]>
@cabo
Copy link
Collaborator

cabo commented Jan 29, 2026 via email

Signed-off-by: Ionut Mihalcea <[email protected]>
@ionut-arm
Copy link
Contributor Author

Thank you, @cabo !

I've made the seccons wording sound less 2119'ish, see f12edd2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants