|
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 <noreply@xxxxxxxx> > Sent: Friday, May 28, 2021 2:24 PM > To: secdir@xxxxxxxx > Cc: draft-ietf-dtn-bpsec-default-sc.all@xxxxxxxx; dtn@xxxxxxxx; last- > call@xxxxxxxx > Subject: [EXT] Secdir last call review of draft-ietf-dtn-bpsec-default-sc-07 > > APL external email warning: Verify sender noreply@xxxxxxxx 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. > |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
