Freshness section slight reorg #91
Conversation
|
Added consolidated text based on Thomas initial version and review from MCR |
draft-ietf-rats-architecture.md
Outdated
| If so, it is the | ||
| signer's (the Attestation Environment's) responsibility to ensure that the values are still correct when they | ||
| are signed. |
There was a problem hiding this comment.
I'm not sure I agree with this. Shouldn't it be covered by the policy? If an attester can only get a stale value and can't vouch for it not having been changed since, then putting that fact in the Evidence allows the verifier to make a decision appropriately.
draft-ietf-rats-architecture.md
Outdated
| This allows associating a "rough" epoch to the Evidence or Attestation Result. | ||
| In this case the epoch is said to be rough because: | ||
|
|
||
| * it is always bound to the set of Claims as a whole, as opposed to having Claim being separately annotated, and | ||
| * it is not possible to distinguish between time of collection from the time of creation of the Claims set. |
There was a problem hiding this comment.
| This allows associating a "rough" epoch to the Evidence or Attestation Result. | |
| In this case the epoch is said to be rough because: | |
| * it is always bound to the set of Claims as a whole, as opposed to having Claim being separately annotated, and | |
| * it is not possible to distinguish between time of collection from the time of creation of the Claims set. |
There was a problem hiding this comment.
I don't think we should ditch this.
The essential premise is on this line. In particular, by using "solely" I wanted to discuss the case where the only clock that the appraiser can trust is its own. The intent of the following text is just to illustrate two common instances where the appraiser can't rely on the peer's clock.
The overall premise for this whole paragraph is that appraiser does not consider any time assertion made the peer, and to determine what kind of information can be used in this case to evaluate freshness.
Clearly, once the peer's clock becomes usable - as in this example - then finer-grained timestamping can become input to the evaluation of the freshness policy as well.
Hopefully I have made my intention clear and the ambiguities in the existing text can be fixed accordingly :-)
draft-ietf-rats-architecture.md
Outdated
| This might be an appropriate choice in case the Attester does not have a reliable clock or time synchronisation is otherwise impaired. | ||
| In this approach, a non-predictable nonce is generated by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result. | ||
| After checking the sent and received nonces are the same, the appraising entity knows that the Claims were signed after the nonce was generated, effectively locking its clock to the produced payload. | ||
| This allows associating a "rough" epoch to the Evidence or Attestation Result. |
There was a problem hiding this comment.
Replace "This" with "Timekeeping" ?
There was a problem hiding this comment.
Not sure: "this" is a bit more than just "timekeeping", it refers to "an approach that places the onus of timekeeping solely on the appraising entity".
There was a problem hiding this comment.
Maybe substitute your text in place of 'this' since the pronoun reference seems ambiguous?
There was a problem hiding this comment.
That seems a bit redundant. I'd like to achieve some kind of compression - obviously without introducing ambiguity. Let me see if I can concoct something decent.
There was a problem hiding this comment.
Ned: please check the proposal in 20e3d7b
draft-ietf-rats-architecture.md
Outdated
|
|
||
| The two basic mechanisms presented above can be extended and combined in more advanced schemes. | ||
| For example, if the clocks are trustworthy but not synchronized, first a nonce-based exchange may be used to determine the (rough) time offset between the involved peers, followed by any number of timestamp based exchanges. | ||
| In another scenario where a broadcast channel is shared by all the RATS entities (Attesters, Verifiers and Relying Parties), the nonce-based approach may be used to lock all parties to the same timeline without requiring synchronized clocks by having a central entity emit nonces at regular intervals and have the "current" nonce included in the produced Evidence or Attestation Result. |
There was a problem hiding this comment.
"Second, a broadcast channel shared by all Roles (Attester, Verifier, etc.), the nonce-based approach..."
There was a problem hiding this comment.
Not sure I understand this suggestion. If the current text isn't good as-is, we may simplify it as "When a broadcast channel is shared by all Roles, the nonce-base approach [...]"
There was a problem hiding this comment.
Trying to get the signposting to match up. In line 880 signposting uses "first" and in 881 signposting changes to "another". Normally, "second" follows "first" - it is just style and I don't feel strongly about it.
There was a problem hiding this comment.
Line 880 and 881 are two separate examples.
The example at line 880 is split in two phases: first [...], followed by [...].
I will remove "first" since it isn't necessary and I suspect it's probably bad English if it got you confused.
There was a problem hiding this comment.
Ned: please check the proposal in 20e3d7b
draft-ietf-rats-architecture.md
Outdated
|
|
||
| A second approach places the onus of timekeeping solely on the appraising | ||
| entity, e.g., the Verifier (for Evidence), or the Relying Party (for | ||
| Attestation Results), and might be suitable in case the Attester does not have |
There was a problem hiding this comment.
I think 'the Attester' here can't cover the case where the Relying Party sends the nonce to the Verifier for retrieving the Attestation Result. Maybe change 'the Attester' to 'the producing entity'?
There was a problem hiding this comment.
-
You are right in that it is not limited to the Attester. I wanted to use the it as the typical example because it's more likely that a constrained Attester doesn't have a very reliable clock. What about:
and might be suitable, for example, in case the Attester does not have [...]? -
The current paragraph looks wrong to me. When it says:
[...] solely on the appraising entity, e.g., the Verifier (for Evidence),
or the Relying Party (for Attestation Results),`
should instead say:
[...] solely on the remote attestation protocol initiator, e.g., the
Relying Party (for Evidence or Attestation Results) and the Attester
(for Attestation Results).
Co-authored-by: Dave Thaler <dthaler@microsoft.com>
change remote entity -> appraising entity
Co-authored-by: Dave Thaler <dthaler@microsoft.com>
For unknown reasons, I can't accept these two via the UI
Co-authored-by: Wei Pan <william.panwei@huawei.com>
fix grammar Co-authored-by: Wei Pan <william.panwei@huawei.com>
This commit slightly changes the Freshness section to reflect the
outcome of the discussion around PR #87. (Hopefully I've managed to
capture the gist of Henk's thinking without disrupting too much the
existing flow.)
TL;DR
The key change here is the removal of reply protection as a goal in
itself. The section now states clearly that the overall goal is instead
the identification of the point in time when attestation claims have
been signed and/or generated so that a freshness policy can be applied.
In this perspective, the fundamental property provided by a nonce-based
scheme with regards to freshness is its ability to lock the requester's
clock to the underlying protocol transaction, thus indirectly
establishing the epoch of the attestation / verification event. By
making the nonce unique and non-predictable, the timeline locking cannot
be subverted, which provides anti-replay. However, that is a nice
side-effect rather than the primary goal.
This commit also adds some precision around the nonce and clock
properties - unpredictability and trustworthiness respectively.