Re: [secdir] [EXT] Secdir early review of draft-ietf-dtn-bpsec-default-sc-02

["Birrane, Edward J." <[e-mail]>]

Christian,

  Thank you so much for this early security review!

  My responses to your comments are included below and enumerated with the convention C# for clarity.


> The first nit regards the table of BIB-HMAC-SHA2 Security Parameters in
> section 3.3.4. The default value for the SHA Variant is specified as "256", but
> section
> 3.3.1 only defines values 5, 6 and 7 for that parameter. I assume that the
> intent is to default to HMAC256/SHA256, but in that case the default should
> be 5, not 256.

C1: Agreed, this is an error in the -02 version of the document, which has been corrected in the -03 version.


> The second nit regards the discussion of authentication and confidentiality in
> section 4.1. AEAD algorithms distinguish between authenticated data and
> encrypted data. The text expresses a different concept,separate definitions
> of "scope of confidentiality" and "scope of authentication". I suggest that
> these paragraphs be rewrittent to specify that "the scope of authentication is
> always the union of the additional data and the scope of confidentiality."

C2: Agreed. The -03 version of the document includes a clarification that the "scope of authentication" to note that it includes the scope of confidentiality in addition to other data.



 > These are small issues. My real concern with this document is the overall
> complexity of the Bundle Protocol and the Security specification. The
> protocols appear specified for maximum flexibility. Messages can be relayed.
> Relays can add their own security blocks to the bundle. Authentication and
> encryption can apply to different blocks in the bundle. Messages can be
> fragmented. Nodes can choose to apply different level of security to
> different bundles, or to different blocks in the same bundle. I suppose that
> these choices are justified by application requirements, but all this
> complexity may end up causing interoperability issues, and potential security
> failures.

C3: Agreed - there is additional complexity in the DTN security suite in general. I see this as more of a comment on the overall DTN ecosystem and not a recommended action on the default security context document.


 
> The way CBOR encoding are used brings another source of complexity. CBOR
> allows for different ways of encoding the same data. The bundle security
> document and this algorithm specification document request that some data
> parts be re-encoded in the "canonical" CBOR format before authentication
> tags are computed or verified. Experience in other domains shows that
> relying on canonization before authentication is very fragile, and a source of
> interoperability failures. It would be much more robust to assume that
> authenticated objects are immutable, and that the wire format of these
> objects is fed directly into the hash algorithm.

C4: The default security context does not, itself, impose stricter canonicalization algorithms as they relate to CBOR - that is done by the BPSec specification. I see this as more of a comment on the BPSec document and not a recommended action on the default security context document.



> To mitigate the risk of interoperability failures, I suggest adding test vectors
> to the specification. Each test case should start with a clear text test bundle,
> apply either authentication or authenticated encryption according to some
> variations of the authentication or AAD scope flags, and produce a result.
> Different test vectors might start with different mode of CBOR encoding, to
> test the canonization process. This kind of investment might save a lot of
> time to future developers!

C5: I agree that a variety of CBOR representations of bundles, blocks, security blocks, and parameter/result combinations would be welcomed by future developers! Since this default security context document uses well-known algorithms I think repeating AES and HMAC/SHA test vectors are not necessary for this document, and general test vectors related to populating security blocks should not be present (and thus, repeated) for all other security context documents being considered. Instead of adding test vectors to this document, I propose taking the request to the DTN WG for how this more largely-scoped information could be best documented. 


 
> Not a comment on this draft, but I see lot of potential issues with
> fragmentation. I understand that in a Delay Tolerant Network,relays need to
> be able to fragment messages. The draft correctly points out that if an
> authenticated message is fragmented, authentication can only be received
> while all fragments are received. However, this would not protect from
> attacks against fragmentation similar to those seen in IP, IPv6 and TCP. I think
> that some kind of secure fragmentation protocol need to be studied and
> specified by the working group.
> 

C6: Similar to C5, I think this topic is larger in scope than the default security context document and agree it, like C5, should be brought to the DTN WG.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839