Re: [dtn] [EXT] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07

["Birrane, Edward J." <[e-mail]>]

Christian,



  Thank you for this updated review.



  I understand and agree with your additional comments on AEAD and have produced a -08 which I hope clarifies options around the handling of the authentication tag.



  Three quick observations:



-           The BCB-AES-GCM security context will always be documented for the GCM mode of AES so, as you say, managing this complexity for AES-GCM is workable. But also agree that for DTN at large, as we work to incorporate newer encryption algorithms, new security context documents will be produced and authentication/encryption can be joined for those documents and algorithms in a less complex way.



-          We are still working with (some) aes-gcm libraries whose APIs separate the authentication tag. For example, the mbedtls (https://www.trustedfirmware.org/projects/mbed-tls/) API uses the function  mbedtls_gcm_crypt_and_tag which takes the tag separately from the cipher text.  For interoperability, pulling the tag into a security result is helpful. If a security source were to produce a blob that represented an unknown ordering of cipher text and authentication tag, then a security destination using mbedtls would not necessarily know where in that blob to pull the tag when constructing the call to mbedtls_gcm_crypt_and_tag. Preferring to extract the tag is clearly more complexity but it also may be helpful when working in networks that have deployed different AES-GCM implementations at different nodes.



-          There has been some discussion where having certain extension blocks be fixed-size would help with processing, which is what made the AES-GCM cipher suite attractive to those uses. Keeping the tag separate is a way to preserve that length constraint in the few cases where that is helpful.



  Again, thank you for your time; these reviews have made the default security context document much more complete and useful.



-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







> -----Original Message-----

> From: Christian Huitema via Datatracker <[e-mail]>

> Sent: Friday, May 28, 2021 2:24 PM

> To: [e-mail]

> Cc: [e-mail]; [e-mail]; last-

> [e-mail]

> Subject: [EXT] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07

>

> APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> before clicking

> links or attachments

>

> Reviewer: Christian Huitema

> Review result: Ready

>

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

>