Skip to main content

Last Call Review of draft-ietf-dtn-bpsec-default-sc-07
review-ietf-dtn-bpsec-default-sc-07-secdir-lc-huitema-2021-05-28-00

Request Review of draft-ietf-dtn-bpsec-default-sc
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-06-01
Requested 2021-05-18
Authors Edward J. Birrane , Alex White , Sarah Heiner
I-D last updated 2021-05-28
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)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-dtn-bpsec-default-sc by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/aCNW_EpoiPO65NxbaE9nREVeTMk
Reviewed revision 07 (document currently at 11)
Result Ready
Completed 2021-05-28
review-ietf-dtn-bpsec-default-sc-07-secdir-lc-huitema-2021-05-28-00
I reviewed draft-ietf-dtn-bpsec-default-sc-02 as part
of an early security review requested by the transport AD. This is the follow-up
last call review of draft-ietf-dtn-bpsec-default-sc-07.

The draft is ready, although I would prefer to see somechanges in the encoding
of AEAD tags as explained below.

The changes in draft-07 address most of the points I made in the early review.
The small nit concerning a reference in the table of BIB-HMAC-SHA2 Security Parameters
is fixed and the implementation of AEAD algorithms is easy to read.

I appreciate that the draft now contains an entire appendix describing examples of messages,
their clear-text encoding and the result of authentication and encryption. This probably
required significant effort, and it does address my suggestion to add test vectors in
order to manage implementation complexity.

I could just say that the draft is ready, except for one addition that I find a bit spurious.
The description of AES-GCM states that "the authentication tag produced by the GCM	
mode of AES is not considered part of the cipher text itself", and that "the	
authentication tag is expected to be carried in the BCB-AES-GCM	security block". The
statement is not technically false, but the separation of message and tag goes against
the design of many AEAD implementations, in which the application provides the
crypto API with a clear text of some length, and retrieves a cipher text of a different
length, including the tag. Separating that tag and moving it to a different location
is yet another way to introduce complexity.

That complexity can probably still be managed for AES-GCM, but the general trend is
to implement encryption and authentication in a single operation. I fully expect that
new encryption algorithms will continue that trend, and may well do away with the
formal separation between ciphertext and tag. Recognizing that encryption and
authentication are not separable would simplify the DTN bundle protocol.