Early Review of draft-ietf-dtn-bpsec-default-sc-02
|Requested rev.||no specific revision (document currently at 11)|
|Team||Security Area Directorate (secdir)|
|Requested by||Magnus Westerlund|
|Authors||Edward Birrane, Alex White, Sarah Heiner|
|Draft last updated||2021-03-18|
Secdir Early review of -02 by Christian Huitema
Genart Last Call review of -07 by Thomas Fossati (diff)
Secdir Last Call review of -07 by Christian Huitema (diff)
Requesting Security review in parallel to enable earlier than last call dealing with any security issues.
|Reviewed rev.||02 (document currently at 11)|
|Review result||Has Nits|
I have reviewed draft-ietf-dtn-bpsec-default-sc-02 as part of an early security review requested by the transport AD. The draft specifies how to use either HMAC/SHA based authencation or AES-GCM authenticated encryption in the framework defined by the Bundle Protocol Security Specification (draft-ietf-dtn-bpsec-27) for the Bundle Protocol Version 7 draft-ietf-dtn-bpbis-31.txt. The specifications are straightforward applications of well-known algorithms: HMAC256/SHA256, HMAC384/SHA384, HMAC512/SHA512, AES128 GCM, and AES256 GCM. The text is written in a detailed manner, guiding potential developers through the implementation of these algorithms. For me, these descriptions seem almost ready, expect for two nits. However, the overall system appears very complex, and some ways to manage that complexity would be welcome. My minimum suggestion would be to add test vectors. 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. 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." 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. 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. 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! 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.