Subject: Re: [dtn] Martin Duke's Discuss on draft-ietf-dtn-bpsec-default-sc-08: (with DISCUSS and COMMENT)

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 29 Jun 2021 20:41:48 +0000

Martin,

  Thank you for the review of the -08 draft!

  My responses are included in-line below.  To help with the discussion, I have enumerated each DISCUSS as D# and each COMMENT as C#.

  If we make the suggested changes below, would they address the concerns listed in the DISCUSS?

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his)
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (4.4.1) says the tag MUST be CBOR encoded and (4.8.1) says the tag MUST be
> reported in the security result; but how is this possible if the tag is not
> extractable from the ciphertext?

I interpreted the above as 2 different DISCUSS topics: CBOR encoding and handling of security results. 

D1: Authentication Tag encoded with CBOR (Recommend no change)

The CBOR encoding is only for the Authentication Tag Security Result Field, which only exists when the authentication tag is not otherwise glued to the cipher text in the target block.  In cases where the tag is glued to the cipher text itself, the Authentication Tag Security Result Field would not be present.

D2: Confusing wording regarding MUST for authentication tag security result (Fix Wording in a -09)

I agree that this wording is confusing. Section 4.4 states that the authentication tag is to be present as a security result only if the tag is not otherwise glued to the cipher text and included in the target block.  But section 4.8.1 says both that the authentication tag must be included as a security result and must be processed in accordance with section 4.4.

I believe this is a typo in section 4.8.1, which should say that the authentication tag MAY be added as a security result and MUST be processed as described in Section 4.4.

> Moreover, shouldn't there be a parameter or a scope flag somewhere that
> tells the receiver if the tag is in the cipher text? It would be hard to discern
> the sender's API a priori!

D3: Tag Placement Flag (Recommend no change)

The authentication tag security result field only exists to hold the tag in the instance when it is not glued to the cipher text. The lack of the security result is the indication that the tag exists with the cipher text in the target block. We would not need another flag or parameter to capture that case.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (4.5) Does "the total number of bytes processed" by AES-GCM include just
> plaintext, or also the associated data?

C1: Bytes processed (Recommend no change)

The total bytes includes both plain text and associated data. 

From Appendix B of the referenced NIST doc: 
"Therefore, the total number of blocks of plaintext and AAD that are protected by invocations of the authenticated encryption function during the lifetime of the key should be limited."

> (6.5) If a security block is cryptographically bound to a bundle, it
>       cannot be processed even if the security block and target both
>       coexist in the fragment.  This is because fragments have different
>       primary blocks than the original bundle.
> 
> This should point out that it only applies if the primary block is part of the
> AAD.

C2: Clarify wording (Agreed - address in a -09)

Our definition of binding to the bundle is including the primary block in the AAD.  Making this explicit here would make that clearer. I can make that change in an upcoming -09.

> (A.4.4.1) It looks like the BIB data is simply a copy of the payload data, and
> therefore incorrect. I didn't check to see if this leads to incorrect values for
> the products of these inputs.

C3: Fix BIB signature (Agreed - address in a -09)

This is a good catch. We will update and make sure any other needed changes are made in an upcoming -09.

---

From: Martin Duke <[email-masked]>
Date: Tue, 29 Jun 2021 15:12:11 -0700

Hi Ed, yes, all of your replies absolutely satisfy my concerns. Thanks!

On Tue, Jun 29, 2021 at 1:41 PM Birrane, Edward J. <
[email-masked]> wrote:

>   My responses are included in-line below.  To help with the discussion, I
> have enumerated each DISCUSS as D# and each COMMENT as C#.
>
> The CBOR encoding is only for the Authentication Tag Security Result
> Field, which only exists when the authentication tag is not otherwise glued
> to the cipher text in the target block.  In cases where the tag is glued to
> the cipher text itself, the Authentication Tag Security Result Field would
> not be present.
>
>
> I agree that this wording is confusing. Section 4.4 states that the
> authentication tag is to be present as a security result only if the tag is
> not otherwise glued to the cipher text and included in the target block.
> But section 4.8.1 says both that the authentication tag must be included as
> a security result and must be processed in accordance with section 4.4.
>
> I believe this is a typo in section 4.8.1, which should say that the
> authentication tag MAY be added as a security result and MUST be processed
> as described in Section 4.4.
>
>
> The authentication tag security result field only exists to hold the tag
> in the instance when it is not glued to the cipher text. The lack of the
> security result is the indication that the tag exists with the cipher text
> in the target block. We would not need another flag or parameter to capture
> that case.
>
>
> >
> "Therefore, the total number of blocks of plaintext and AAD that are
> protected by invocations of the authenticated encryption function during
> the lifetime of the key should be limited."
>
>
> Our definition of binding to the bundle is including the primary block in
> the AAD.  Making this explicit here would make that clearer. I can make
> that change in an upcoming -09.
>
>