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

["R. Atkinson" <[e-mail]>]

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. <[e-mail]> wrote:
> 
> 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.

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 adds options later. The default security context is meant to be a simple, secure context (others are coming). 

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 authentication tag as a security result in the BCB itself (section 4.4.1). 

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