Early Review of draft-ietf-dtn-bpsec-default-sc-02
review-ietf-dtn-bpsec-default-sc-02-secdir-early-huitema-2021-03-18-00

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.