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.