Subject: [dtn] Secdir early review of draft-ietf-dtn-bpsec-default-sc-02

From: Christian Huitema via Datatracker <[email-masked]>
Date: Thu, 18 Mar 2021 18:25:34 -0700

Reviewer: Christian Huitema
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.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 29 Mar 2021 03:06:39 +0000

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
> 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.

> 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.

> 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
> 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. 

> 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