Stu's comments

[ShuaiZhao]

My previously raised issues still need attention as follows.

1.1 last paragraph "UAS RID" should be used only to refer to the need, process and system, not the identifier. Shuai: Please replace "The UAS RID discussed in Section 3" with "The DRIP Entity Tag discussed in Section 3".

3.2 "(more details in Section 8)" is no longer accurate as security considerations have been reworded so specific vulnerabilities are stated more generally and seem less dangerous. :-( Shuai: Please replace "(more details in Section 8)" with simply "(see also Section 8)".

8. "Thus an adversary could impersonate a validly registered UA. This attack would only be exposed when the HI in DRIP authentication message is checked back to the USS and found not to match." is incorrect as this attack is defeated by broadcasting registry attestations on UA etc. as described in -auth, which unfortunately still lacks, in -arch, the introduction provided therein for -rid (actually -dets) and -registries. Shuai: Please replace the above text with "Thus, if a receiver were to check HHIT validity only by verifying that the received HI and associated information, when hashed in the ORCHID construction, reproduce the received HHIT, an adversary could impersonate a validly registered UA. To defend against this, on-line receivers should verify the received HHIT and received HI with the USS with which the HHIT purports to be registered. On-line and off-line receivers can use a chain of received DRIP Link attestations from a root of trust through the RAA and the HDA to the UA, as described in [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries]." Also please add [I-D.ietf-drip-registries] to the informative references and cite it in Section 4.

9. "Finally,..." states one vulnerability, then 3 more unrelated to the first. Shuai: Please replace "Finally, the UAS RID sender" with simply "The UAS RID sender".

Throughout, may/MAY/should/SHOULD/must/MUST still need review, IMO they have been excessively weakened.

Thanks!

[ShuaiZhao]

Stu:

3.2 "(more details in Section 8)" is no longer accurate as security considerations have been reworded so specific vulnerabilities are stated more generally and seem less dangerous. :-( Shuai: Please replace "(more details in Section 8)" with simply "(see also Section 8)".

Shuai/ Done

[ShuaiZhao]

Stu:

1.1 last paragraph "UAS RID" should be used only to refer to the need, process and system, not the identifier. Shuai: Please replace "The UAS RID discussed in Section 3" with "The DRIP Entity Tag discussed in Section 3".

Done

[ShuaiZhao]

Stu:

"Thus an adversary could impersonate a validly registered UA. This attack would only be exposed when the HI in DRIP authentication message is checked back to the USS and found not to match." is incorrect as this attack is defeated by broadcasting registry attestations on UA etc. as described in -auth, which unfortunately still lacks, in -arch, the introduction provided therein for -rid (actually -dets) and -registries. Shuai: Please replace the above text with "Thus, if a receiver were to check HHIT validity only by verifying that the received HI and associated information, when hashed in the ORCHID construction, reproduce the received HHIT, an adversary could impersonate a validly registered UA. To defend against this, on-line receivers should verify the received HHIT and received HI with the USS with which the HHIT purports to be registered. On-line and off-line receivers can use a chain of received DRIP Link attestations from a root of trust through the RAA and the HDA to the UA, as described in [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries]." Also please add [I-D.ietf-drip-registries] to the informative references and cite it in Section 4.

Shuai/ both places are updated

[ShuaiZhao]

Stu:

"Finally,..." states one vulnerability, then 3 more unrelated to the first. Shuai: Please replace "Finally, the UAS RID sender" with simply "The UAS RID sender".

Shuai/ Bob has proposed new text in new subsection "8.1. Private key physical security" and it was solved.

[ShuaiZhao]

Stu:

Throughout, may/MAY/should/SHOULD/must/MUST still need review, IMO they have been excessively weakened.

Shuai/ I agree. there are places where they were addressed already based on the IESG review. Are there any other places you think we need to address? I recalled AD and Chairs rely on authors to make a correct choice since it is an informative draft.

[cardsw]

Thanks.

Stu:

3.2 "(more details in Section 8)" is no longer accurate as security
considerations have been reworded so specific vulnerabilities are stated
more generally and seem less dangerous. :-(
Shuai: Please replace "(more details in Section 8)" with simply "(see also
Section 8)".

Shuai/ Done

-- Reply to this email directly or view it on GitHub: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/43#issuecomment-1148993327 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

-- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) @.***>

[cardsw]

Thanks.

Stu:

1.1 last paragraph "UAS RID" should be used only to refer to the need, process and system, not the identifier. Shuai: Please replace "The UAS RID discussed in Section 3" with "The DRIP Entity Tag discussed in Section 3".

Done

-- Reply to this email directly or view it on GitHub: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/43#issuecomment-1148996911 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

-- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) @.***>

[cardsw]

Thanks.

Stu:

"Finally,..." states one vulnerability, then 3 more unrelated to the first. Shuai: Please replace "Finally, the UAS RID sender" with simply "The UAS RID sender".

Shuai/ Bob has proposed new text in new subsection "8.1. Private key physical security" and it was solved.

-- Reply to this email directly or view it on GitHub: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/43#issuecomment-1149013604 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

-- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) @.***>

[cardsw]

I will scan all occurrences of such keywords on your latest (-23?) & identify any that seem too weak (or too strong).

Stu:

Throughout, may/MAY/should/SHOULD/must/MUST still need review, IMO they have been excessively weakened.

Shuai/ I agree. there are places that were addressed based on the IESG review. Are there any other places you think we need to address?

-- Reply to this email directly or view it on GitHub: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/43#issuecomment-1149015185 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

-- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) @.***>

[cardsw]

Thanks!

Stu:

"Thus an adversary could impersonate a validly registered UA. This attack would only be exposed when the HI in DRIP authentication message is checked back to the USS and found not to match." is incorrect as this attack is defeated by broadcasting registry attestations on UA etc. as described in -auth, which unfortunately still lacks, in -arch, the introduction provided therein for -rid (actually -dets) and -registries. Shuai: Please replace the above text with "Thus, if a receiver were to check HHIT validity only by verifying that the received HI and associated information, when hashed in the ORCHID construction, reproduce the received HHIT, an adversary could impersonate a validly registered UA. To defend against this, on-line receivers should verify the received HHIT and received HI with the USS with which the HHIT purports to be registered. On-line and off-line receivers can use a chain of received DRIP Link attestations from a root of trust through the RAA and the HDA to the UA, as described in [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries]." Also please add [I-D.ietf-drip-registries] to the informative references and cite it in Section 4.

Shuai/ both places are updated

-- Reply to this email directly or view it on GitHub: https://github.com/ietf-wg-drip/draft-ietf-drip-arch/issues/43#issuecomment-1149011787 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

-- Stuart W. Card, VP & Chief Scientist Critical Technologies Inc. (CTI) @.***>