[dtn] feedback on draft-birrane-dtn-bpsec-interop-cs-01 was Re: New document acceptance

[Mehmet Adalier <[e-mail]>]

I do believe that the draft-birrane-dtn-bpsec-interop-cs-01 is valuable work for the WG.

I like the layout and per "Second, this specification can serve as a template to be followed by other BPSec cipher suite authors," 
I am using this as a template for another cipher suite. Thanks Ed:)
 
We do have running code based on Ed's BPsec code+ ION and our crypto libraries that implement this draft.

I have a few specific questions/suggestions:
1. Regarding AAD use with GCM. Why is this disallowed? Or did I read it wrong? 
2. Would be it be possible to make AAD optional?
	(i.e., input plain text and AAD as separate buffers), length of AAD buffer is passed in the security header, 0 indicating no AAD.
	AAD length can be restricted to 16bytes (AES block length) to make implementations easier.
	This is what our implementation does at the moment.
3. I would strongly suggest that the IV is more restricted.
	NIST and other research recommend that for IVs: “GCM implementations restrict support to the length of 96 bits, to promote interoperability, 
	efficiency, and simplicity of design.” See SP-800-38D
	Having implemented GCM both on x86, ARM in C & Assembly... implementations using other IV lengths are quite complex, error prone, and require additional cycles.
	See snippet below:
		If len(IV)=96, then let J0 = IV || 0^31 ||1. //that is 31 0s		
		If len(IV) ≠ 96, then let s = 128 ⎡len(IV)/128⎤-len(IV), and let
		J0=GHASHH(IV||0^(s+64)||[len(IV)]base 64).

	I suggest that the IV is set to 96-bits (12-bytes) (i.e., make it a MUST). internally with the inclusion of the counter bits, J0 will end up being 16 bytes

4. I would suggest strong language that the IV MUST be fresh for each use
	A fresh IV must be generated via a Deterministic Random Number Generator as specified by NIST, per instantiation of the GCM algorithm. 
	This IV must not be used for other operations. 
	A breach of the requirement for the uniqueness of the initialization strings may compromise the security assurance *almost entirely*.


I have also read draft-birrane-dtn-ama. This sounds very interesting and would like to further study to investigate a potential implementation using CoAP-over-bp

Best,
Mehmet Adalier
Antara Teknik LLC

 On 4/12/18, 6:41 AM, "dtn on behalf of Rick Taylor" <[e-mail] on behalf of [e-mail]> wrote:

    Hi All,
    
    At IETF 101 London, the authors of the following documents request WG
    acceptance:
    
     * Asynchronous Management Architecture: draft-birrane-dtn-ama
    
     * BPSec Interoperability Cipher Suites: draft-birrane-dtn-bpsec-
    interop-cs
    
    Both of these documents match work items in the charter.  I believe
    there is rough consensus on their acceptance.
    
    Please comment promptly if you do *not* believe these documents are not
    valuable work for the WG, otherwise they will be accepted.
    
    Cheers,
    
    Rick
    _______________________________________________
    dtn mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dtn