Early Review of draft-ietf-dtn-bpsec-default-sc-02

Request Review of draft-ietf-dtn-bpsec-default-sc
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2021-03-26
Requested 2021-03-09
Requested by Magnus Westerlund
Authors Edward Birrane, Alex White, Sarah Heiner
Draft last updated 2021-03-18
Completed reviews Secdir Early review of -02 by Christian Huitema (diff)
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.
Assignment Reviewer Christian Huitema 
State Completed
Review review-ietf-dtn-bpsec-default-sc-02-secdir-early-huitema-2021-03-18
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Y2Y5mafRx1SF4Bdln7Y6FW4dti0
Reviewed rev. 02 (document currently at 11)
Review result Has Nits
Review completed: 2021-03-18


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.