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

[Benjamin Kaduk <[e-mail]>]

Hi Christian,

Thanks for the spot-on review!  BP security is indeed pretty complicated
with all those moving pieces, and I agree that test vectors would help give
confidence in correctness of implementations.

I had good experiences working with Ed on other DTN documents (the worst
part was self-induced delay on my part), so I expect that the WG will be
pretty receptive to your suggestions.

Thanks again,

Ben

On Thu, Mar 18, 2021 at 06:25:34PM -0700, Christian Huitema via Datatracker wrote:
> 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.
> 
> 
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview