Subject: Re: [dtn] AD review of draft-ietf-dtn-bpsec-default-sc-02

From: Martin Duke <[email-masked]>
Date: Wed, 12 May 2021 14:17:38 -0700

Hello DTN,

As Zahed is still on medical leave, I have conducted a partial review of
draft-ietf-dtn-bpsec-default-sc-06 to check that it fully complies with the
outcome of his AD review. I apologize for any errors due to my insufficient
context -- I have not read the entire draft yet.

(3.3.2) I appreciate the new Key Management section, but I don't want to
lose part of Zahed's original review -- does the key wrapping [AES-KW]
include enough metadata that the receiver can select the correct cipher and
key to use without having to do trial decryption?

(3.3.3) IMO the discussion about a registry for Integrity Scope Flags
petered out with a clear resolution -- are the authors of the opinion that
use of more of these flags is simply inconceivable? A registry would
provide guidelines for how to assign more of these in future.

(4.1) In item (3), it states "The use of the Galois/Counter Mode produces
cipher-text with the
       same size as the plain text". My understanding of GCM is that there
is a 128 or 256 bit authentication tag appended to it that makes the whole
of the cipher text larger than the plaintext.  Is this a semantic thing, am
I wrong, or are you wrong?

(6.1) I fear that you successfully scrubbed sc-02 for lower-case normative
words, but then added new stuff here. Specifically:

"must be able to perform the following activities"

"This may include pre-sharing of key encryption keys"

Please verify that these should not be capitalized.

Regards,
Martin

---

From: Mehmet Adalier <[email-masked]>
Date: Wed, 12 May 2021 15:52:20 -0700

Dear Martin,

I am not the author but please see a couple of answers below:

From: dtn <[email-masked]> on behalf of Martin Duke <[email-masked]>
Date: Wednesday, May 12, 2021 at 2:42 PM
To: <[email-masked]>
Cc: Zaheduzzaman Sarker <[email-masked]>
Subject: Re: [dtn] AD review of draft-ietf-dtn-bpsec-default-sc-02

Hello DTN,

As Zahed is still on medical leave, I have conducted a partial review of draft-ietf-dtn-bpsec-default-sc-06 to check that it fully complies with the outcome of his AD review. I apologize for any errors due to my insufficient context -- I have not read the entire draft yet.

(3.3.2) I appreciate the new Key Management section, but I don't want to lose part of Zahed's original review -- does the key wrapping [AES-KW] include enough metadata that the receiver can select the correct cipher and key to use without having to do trial decryption?

mA>>If one implements the AES-KW as indicated in the referenced NIST SP800, there should be no interop issues (i.e., no need to do a trial decryption). The AES-KW cipher and any “metadata” are pre-determined, but one can use either 128 or 256-bit keys.

(3.3.3) IMO the discussion about a registry for Integrity Scope Flags petered out with a clear resolution -- are the authors of the opinion that use of more of these flags is simply inconceivable? A registry would provide guidelines for how to assign more of these in future.

(4.1) In item (3), it states "The use of the Galois/Counter Mode produces cipher-text with the
       same size as the plain text". My understanding of GCM is that there is a 128 or 256 bit authentication tag appended to it that makes the whole of the cipher text larger than the plaintext.  Is this a semantic thing, am I wrong, or are you wrong? 

mA>>The Authentication Tag is not considered as part of the ciphertext. With BPsec the tag is stored separate from the ciphertext. On receiving a ciphertext +tag, the AES-GMC process includes calculating the Authentication Tag on the ciphertext and comparing it to the received Tag, which is separate from the decryption algorithm.

(6.1) I fear that you successfully scrubbed sc-02 for lower-case normative words, but then added new stuff here. Specifically:

Regards,

Martin

_______________________________________________ dtn mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Wed, 12 May 2021 23:08:49 +0000

Martin,

  Thank you for continuing the review!

  My apologies for the top post – I am having some problems with my e-mail client and HTML quoting.

  (3.3.2):  AES-KW does not use an IV and wrapped keys are required to be 8 byte multiples so we won’t have padding. There is no additional info that needs to be in the BCB to assist with unwrap.  Key width comes from the AES Variant parameter.

  (3.3.3): Certainly not inconceivable! But we (DTNWG) can’t think of any that are motivating at this time.  I am concerned that adding this complexity would make interoperability harder if someone adds options later. The default security context is meant to be a simple, secure context (others are coming).

  (4.1): This is a semantic thing. The authentication tag is not considered part of the cipher text itself (though some APIs may catenate them). This security context will try and place the authentication tag as a security result in the BCB itself (section 4.4.1).

  (6.1): Neither of these is meant to be normative. In a -07 I can correct the language to avoid must and may to avoid any misinterpretation.

-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

From: dtn <[email-masked]> On Behalf Of Martin Duke
Sent: Wednesday, May 12, 2021 5:18 PM
To: [email-masked]
Cc: Zaheduzzaman Sarker <[email-masked]>
Subject: [EXT] Re: [dtn] AD review of draft-ietf-dtn-bpsec-default-sc-02

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before clicking links or attachments

Hello DTN,

Regards,
Martin

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 14 May 2021 09:12:17 -0400

All,

All of my comments are non-blocking editorial requests.

My principle is simple.  With 30 years experience so far, every IETF protocol I am aware of eventually is implemented by a naive software person who is NOT involved in the IETF at all.  So if the current text raises questions about meaning/clarity/intent among anyone reviewing the document from an IETF context, it is highly likely those questions also will arise in the mind of the naive implementer who has to code this in future at some point.  

So best (IMHO) to clarify the text, even if there is no change to the meaning/intention.

> On May 12, 2021, at 19:08, Birrane, Edward J. <[email-masked]> wrote:
> 
> Martin,
>  

Maybe please add the text above (or edited text to your taste) to the draft to improve readability/clarity for naive implementers who are not experts in key wrapping.

>   (3.3.3): Certainly not inconceivable! But we (DTNWG) can’t think of any that are motivating at this time.  I am concerned that adding this complexity would make interoperability harder if someone…

If they are not explicitly prohibited in the draft, then I think a Registry needs to be created.  If the text is ambiguous, please either add clear new text with the prohibition xor add the Registry related text,

>   (4.1): This is a semantic thing. The authentication tag is not considered part of the cipher text itself (though some APIs may catenate them). This security context will try and place the authent…

That text is great, but please place an edited version of that directly into the draft.  Ordinary software developers will not understand this ab initio; it needs to be stated clearly.

>   (6.1): Neither of these is meant to be normative. In a -07 I can correct the language to avoid must and may to avoid any misinterpretation.

My request would be to go through the draft and look at each instance of “may” or “MAY” and see whether it would be more clear to say “might” (lowercase; non-normative).

For non-native readers of English, it is very confusing that colloquial English uses the word “may” with 2 very different meanings:

(a) a possible event — “It may rain this afternoon.”
(b) permission - “Mary may skip school today.”

For the intended meaning of (a) above, it would be much more readable if the word “might” were substituted for “may”. 

[ Aside: I wish the RFC Editor would pursue this issue more often than it seems to.  Maybe the new WG on terminology can pick this issue up and run with it.  ]

Cheers,

Ran

---

From: Martin Duke <[email-masked]>
Date: Fri, 14 May 2021 12:01:55 -0700

OK, so there's a slight revision of (6.1), possibly Ran's other editorial
comments, and we have to resolve this registry issue.

IMO interoperability problems are an issue for whomever writes the
extension, not for you. For a flag that changes the format, this would have
to be negotiated. For something that doesn't, it might just provide
additional information or trigger some other behavior that doesn't break
the whole decrypt operation. I am not going to lie down in the road on this
registry issue (though Zahed might?) but it's a pretty small bit of text
and one decision on what RFC 8126 policy to use.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 14 May 2021 19:23:35 +0000

Ran,

  I’m always open to adding explanatory material here – and it’s good to get feedback on what things require that kind of clarification.

Martin,

  I am, personally, not opposed to a registry. As you said, it is a little bit of text.  Happy to add it based on your thoughts regarding future interop.

  I will update the -06 draft as discussed so far in this thread.  I think the upcoming -07 would resolve AD comments so far. Is that correct?

-Ed

---

From: dtn <[email-masked]> On Behalf Of Martin Duke
Sent: Friday, May 14, 2021 3:02 PM
To: R. Atkinson <[email-masked]>
Cc: Zaheduzzaman Sarker <[email-masked]>; DTN WG <[email-masked]>
Subject: Re: [dtn] [EXT] Re: AD review of draft-ietf-dtn-bpsec-default-sc-02

OK, so there's a slight revision of (6.1), possibly Ran's other editorial comments, and we have to resolve this registry issue.

IMO interoperability problems are an issue for whomever writes the extension, not for you. For a flag that changes the format, this would have to be negotiated. For something that doesn't, it might just provide additional information or trigger some other behavior that doesn't break the whole decrypt operation. I am not going to lie down in the road on this registry issue (though Zahed might?) but it's a pretty small bit of text and one decision on what RFC 8126 policy to use.

---

From: Martin Duke <[email-masked]>
Date: Fri, 14 May 2021 12:33:32 -0700

I believe that fully captures Zahed's review, yes.

On Fri, May 14, 2021 at 12:23 PM Birrane, Edward J. <
[email-masked]> wrote:

> Ran,
>
>
>
>   I’m always open to adding explanatory material here – and it’s good to
> get feedback on what things require that kind of clarification.
>
>
>
> Martin,
>
>
>
>   I am, personally, not opposed to a registry. As you said, it is a little
> bit of text.  Happy to add it based on your thoughts regarding future
> interop.
>
>
>
>   I will update the -06 draft as discussed so far in this thread.  I think
> the upcoming -07 would resolve AD comments so far. Is that correct?
>
>
>
> -Ed
>
>
>
> ---
> *From:* dtn <[email-masked]> *On Behalf Of *Martin Duke
> *Sent:* Friday, May 14, 2021 3:02 PM
> *To:* R. Atkinson <[email-masked]>
> *Cc:* Zaheduzzaman Sarker <[email-masked]>; DTN WG <
> [email-masked]>
> *Subject:* Re: [dtn] [EXT] Re: AD review of
> draft-ietf-dtn-bpsec-default-sc-02
>
>
>
> *APL external email warning: *Verify sender [email-masked] before
> clicking links or attachments
>
>
>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Tue, 18 May 2021 21:02:35 +0000

Martin,

  I have pushed a -07 version of the document which I believe addresses the requested changes.

-Ed

---

From: Martin Duke <[email-masked]>
Sent: Friday, May 14, 2021 3:34 PM
To: Birrane, Edward J. <[email-masked]>
Cc: R. Atkinson <[email-masked]>; Zaheduzzaman Sarker <[email-masked]>; DTN WG <[email-masked]>
Subject: Re: [dtn] [EXT] Re: AD review of draft-ietf-dtn-bpsec-default-sc-02

APL external email warning: Verify sender [email-masked]<mailto:[email-masked]> before clicking links or attachments

On Fri, May 14, 2021 at 12:23 PM Birrane, Edward J. <[email-masked]<mailto:[email-masked]>> wrote:
Ran,

Martin,

-Ed

---

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Duke
Sent: Friday, May 14, 2021 3:02 PM
To: R. Atkinson <[email-masked]<mailto:[email-masked]>>
Cc: Zaheduzzaman Sarker <[email-masked]<mailto:[email-masked]>>; DTN WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] [EXT] Re: AD review of draft-ietf-dtn-bpsec-default-sc-02

---

From: Martin Duke <[email-masked]>
Date: Tue, 18 May 2021 14:35:14 -0700

Alright, I've shipped it to Last Call.

On Tue, May 18, 2021 at 2:02 PM Birrane, Edward J. <
[email-masked]> wrote:

> *From:* Martin Duke <[email-masked]>
> *Sent:* Friday, May 14, 2021 3:34 PM
> *To:* Birrane, Edward J. <[email-masked]>
> *Cc:* R. Atkinson <[email-masked]>; Zaheduzzaman Sarker <
> [email-masked]>; DTN WG <[email-masked]>
> *APL external email warning: *Verify sender [email-masked]
> before clicking links or attachments
>
>
>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Mon, 24 May 2021 15:25:25 +0000

Thanks all for work on this and progressing this.

BR
Zahed

On 2021-05-18, 23:35, "Martin Duke" <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, May 18, 2021 at 2:02 PM Birrane, Edward J. <[email-masked]<mailto:[email-masked]>> wrote:
Martin,

-Ed

---

From: Martin Duke <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 14, 2021 3:34 PM
To: Birrane, Edward J. <[email-masked]<mailto:[email-masked]>>
Cc: R. Atkinson <[email-masked]<mailto:[email-masked]>>; Zaheduzzaman Sarker <[email-masked]<mailto:[email-masked]>>; DTN WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] [EXT] Re: AD review of draft-ietf-dtn-bpsec-default-sc-02

Martin,

-Ed

---