Security Considerations - nonce explanation

[siethower]

Comment from Toerless to section 10

2791    10.1.  Denial of Service (DoS) Attack on Pledge   2793       Disrupting the pledge behavior by a DoS attack may prevent the 2794       bootstrapping of the pledge to a new domain.   2796       A DoS attack with a faked registrar-agent may block the bootstrapping 2797       of the pledge due to state creation on the pledge (the pledge may 2798       produce a voucher-request, and refuse to produce another one).  One 2799       mitigation may be that the pledge does does not limited the number of 2800       voucher requests it creates until at least one has finished, or a 2801       single onboarding state may expire after a certain time.   The way i remember, the nonce is really only meant to protect against replay attack from e.g. a prior owner: Owner generates voucher, then sells box, new owner takes ownership with new voucher, then sneaky prior owner re-owns pledge (after some partial reset) with prior voucher and then gains access to some not-fully reset information about the second owner on the pledge.   The way to protect against this is IMHO to simply not issue new nonce values for every voucher request thats is triggered, but only to generate a new nonce after the pledge is presented with a successful voucher for the prior nonce. and remember the prior nonce value as "do-not-reuse". For example by having a persistent (e.g.: TPM based) RNG for the nonce. Thats just one more persistent number to remember.   Maybe write something like that.

[stfries]

Proposal to change the original text to the following:

"A DoS attack with a faked registrar-agent may block the bootstrapping of the pledge due to state creation on the pledge (the pledge may produce a voucher-request, and refuse to produce another one). One mitigation may be that the pledge does not limited the number of voucher-requests it creates until at least one has finished. An alternative may be that the onboarding state may expire after a certain time, if no further interaction has happened. "

Proposal to add further info based on Toerless' comment as: "In addition, the pledge may assume that repeated trigger voucher requests are the result of a communication error with the registrar-agent. In that case the pledge MAY simply resent the pledge-voucher request previously sent. Note that in case of resending, a contained nonce and also the contained agent-signed-data in the pledge-voucher-request would consequently be reused."

This may need further discussion as we should not have a deadlock through resending pledge-voucher-requests even if contacted from a different registrar-agent.

[siethower]

small finding:

• "due to state creation on the pledge" may be better use "due to changing state on the pledge"
• "repeated trigger voucher requests" may be better use "repeated triggering for PVR"

[stfries]

considered proposal and improvements in the latest commit. Left open for Toerless to review

[toerless]

First, it seems we should have a sentence stating why we even need to re-specify things here over rfc8995:

Because in PRM, the pledge responds to requests from real or illicit registrar-agents, pledges are more subject to DoS attacks from registrar-agents in PRM than they are from illicit registrars in RFC8995 where pledges do initiate the connections.

Secondly, the current text:

2799 One mitigation may be that the pledge does does not limited the number of 2800 voucher requests it creates until at least one has finished, or a 2801 single onboarding state may expire after a certain time.

Is not very practical. It would imply that the pledge would have to remember as many nonces as it receives fake requests. This is what i wanted to avoid. RFC8995 says that every request needs a new nonce, but that only makes sense when the pledge is initiator (IMHO). Because then it is at control.

Aka: recommendation would be to only generate new nonces at a frequency that an rfc8995 plede would also create new nonces (requests). And re-use the same nonce for all received prm requrests in the time window. And add a statement that a PRM pledge SHOULD derive its nonce from a PRG, ideally one from a TPM, so that it would not re-use the same nonce with very high likelyhood, even across reboots.

[toerless]

Discuss in BRSKI call: Michael: need to throttle generation of replies, not because of nonce, but because its expensive to sign the message (from pledge).

otherwise reuse of nonce for some period of time, to avoid having to remember too many nonce is fine.

[stfries]

Added explanation in latest submit

may be closed