[dtn] AD review of draft-ietf-dtn-bpsec-default-sc-02

[Zaheduzzaman Sarker <[e-mail]>]

Hi,

Thanks for the work done to specify the default security context for BPsec. As I understand this specification is important for interoperability of BPsec.

I found this document easy to read and carefully written. However, I have found number of cases those need clarifications and fix nits. Please see below –

* Abstract :
    The BPsec specification says -

  	"To ensure interoperability among various implementations, all BPSec
  	 implementations MUST support at least the current IETF standards-
   	track mandatory security context(s).  As of this writing, that BCP
   	mandatory security context is specified in
    	[I-D.ietf-dtn-bpsec-default-sc], but the mandatory security
    	context(s) might change over time in accordance with usual IETF
    	processes.  Such changes are likely to occur in the future if/when
   	flaws are discovered in the applicable cryptographic algorithms, for
    	example.".

   This makes the default SC is a MUST to implement for interoperability. However, the abstract writes

   	"These security contexts may be used for
   	both testing the interoperability of BPSec implementations and for
   	providing basic security operations when no other security contexts
   	are defined or otherwise required for a network. "

    I would suggest to replace "may be" with "intended to be".

* Terminology :
     Section 4.6 : please check in normative text are correctly following RFC8174.
     Section 6.1 : please check in normative text are correctly following RFC8174.

* It would be good for the user of this document to capture the reason behind selecting HMAC-SHA and AES-GCM in respective overview section (section 3.1 and section 4.1).

* Section 3.1 :
	These variants correspond
	to HMAC256-SHA256, HMAC384-SHA384, and HMAC512-SHA512 as defined in
	[RFC8152] Table 7: HMAC Algorithm Values.

      Names does not match table names in RFC8152. I understand it might be desirable to use the longer form that makes it clear that this is SHA256/384/512 version of HMAC. However, in that case I think an explicit mapping needs to occur in this document.

      Again the name does not match how it is written in section 3.1 and 3.3.1.

* Section 3.3.2 and Section 3.5 :
    I foresee some issues here about key management i.e., picking up the correct key. The assumption here is that the key management will able to figure out the correct key to be used. However, in many key management functions (BPsec does not specify any) one will derive specific keys, use them and replace them later. This means there are chances that different keys will be available over time in the nodes. How do you identify the correct key in such a scenario, especially when the key is derived from the material carried in the BIB?   It seems like some sort of key-id might be required to resolve this. The BPsec does not define any generic key-id and it is neither defined here. It might become an issue for interoperability.

* Section 3.3.3:
   Two aspects here -
    1. Why are so many bits used for flags? I tried to back track it to BPsec and BP documents but I am not sure I found what I was looking for.
    2. if the plan here is to assign in future (bits 8-15) then an procedure need to be in place to assign them (even in an abstract form). The future assignment will also impact 3.3.6 and 3.7 as the unknow bits will lead to failure as the flag value is part of the IPPT and receiver does not know what to add based on the bits. What is the thinking here?

* Section 3.3.4:
    I would suggest to add a reference to BPsec 3.1 here.
    Nit: ID 1 should have default value 6, or if the intention here is to use SHA256 then it should be 5 instead (as mentioned in the early SECART review).

* Section 3.6 :
     Is there any particular reason for defining the flag bits in the order  - primary block flag, target header flag and security header flag but for canonical form process the order is primary block flag, security header flag and target header flag?

    Nit: in the process description text "flag" is written in both uppercase and lower case.


* Section 3.7.1 :
	Any local flags used to generate the IPPT SHOULD be placed in the
     	 Integrity Scope flags security parameter for the BIB unless these
     	 flags are expected to be correctly configured at security
      	verifiers and acceptors in the network.

    I assume that security acceptor and verifiers will have to use the actual value provided in the Integrity scope flags unless they are correctly configured. This sounds like the local flags used to generate the IPPT MUST be placed in the Integrity Scope flags. Is there any reason why this is SHOULD not a MUST?

* Section 3.7.2 :
      This section should also say any error on verification should result in failure. Something similar to the text in the section 4.8.2

* Section 4 :
     Several of above mentioned issues are also applicable to subsections of section 4.

* Section 4.3.2 :

	When not provided, implementations SHOULD assume a value of 3
   	(indicating use of A256GCM), unless an alternate default is
   	established by security policy at the security source, verifier, or
   	acceptor of this integrity service.

     Does this "security policy" refers to local security policy?

* Section 5:
      As mentioned before registries for Scope flags will be necessary.

* Section 6.3

     To me this security considerations for fragmentation belongs to BPsec as the main technical issues on fragmentation are described there.


I would also like to draw attention to the SECART review (Thanks to the SECART team and Christian Huitema) proposing test vectors to mitigate interoperability issue pointed out by the reviewer. This seems like a good proposal to include in this specification.

Many thanks!!

Zahed