-
Notifications
You must be signed in to change notification settings - Fork 1
Add security considerations #52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Ionut Mihalcea <[email protected]>
5055153 to
0e67d4c
Compare
|
cc @junzhanghw |
|
seems good. |
thomas-fossati
left a comment
There was a problem hiding this 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.
draft-ietf-rats-epoch-markers.md
Outdated
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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]>
Signed-off-by: Ionut Mihalcea <[email protected]>
Considerations in that section are more fundamental than seccons. Signed-off-by: Ionut Mihalcea <[email protected]>
|
On Jan 27, 2026, at 16:42, Thomas Fossati ***@***.***> wrote:
As a general comment, there is some reluctance to use RFC 2119 language in the security considerations. We may want to change all the capitalised verbs to lowercase.
… the reason being that if there are protocol requirements following from the security considerations, these should already have been stated in the protocol definition and not just be mentioned later in a deliberative section (“… considerations”).
To avoid confusion (*) about lower case words, I’d use different phrases, such as “needs to” for “MUST” or “generally needs to” for SHOULD.
This also works better with the fact that these passages are mainly really statements of facts instead of normative language.
Grüße, Carsten
(*) Which really should have been over with RFC 8174, which we are all eagerly citing, but old habits...
|
Signed-off-by: Ionut Mihalcea <[email protected]>
Partly addresses #54