Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Going from memory (and not having read the other threads), I think it
should be possible to write things such that automatic key exchange is
not a normative dependency at this time (pending future update).

-Ben

On Mon, Feb 17, 2020 at 09:18:43AM +0000, Magnus Westerlund wrote:
> Hi,
> 
> Adding the Sec ADs to this discussion. To resolve the whole chain of security
> related issues here.
> 
> I don't see any major issue with the below plan except for how we handle the
> fact that there will not be an automatic key-exchange available for DTN nodes
> immediately and that this is only in the WG's plans. 
> 
> Is there anything better we can do than to promise to update either BPSec or the
> interoperability security context document with the automatic key-exchange
> solution when it is available? Or is the whole of the DTN work going to hang in
> the RFC-editor queue until those components are available? I would really like
> to avoid that. 
> 
> Cheers
> 
> Magnus
> 
> 
> On Mon, 2020-02-17 at 04:17 +0000, Birrane, Edward J. wrote:
> > Ran,
> > 
> >   I do recall that you made this same point at one of the DTNWG meetings.  
> > 
> >   It seems the desired way forward would be to 
> > 
> > 1. Take the current bpsec interoperability security contexts document (draft-
> > ietf-dtn-bpsec-interop-sc) and make it a normative reference in bpsec.
> > 2. State in the new section 9.1 of BpSec that the interop security contexts
> > are mandatory-to-implement.
> > 3. Put the interop security contexts into the review cycle (they are in WG
> > last call at this point, I believe).
> > 
> > Would this be a satisfactory outcome?
> > 
> > -Ed
> > 
> > 
> > Edward J. Birrane, III, Ph.D.
> > Embedded Applications Group Supervisor
> > Principal Staff, Space Exploration Sector
> > Johns Hopkins Applied Physics Laboratory
> > (W) 443-778-7423 / (F) 443-228-3839
> > 
> > -----Original Message-----
> > From: dtn <[e-mail]> On Behalf Of R. Atkinson
> > Sent: Thursday, February 13, 2020 5:17 PM
> > To: DTN WG <[e-mail]>
> > Cc: The IESG <[e-mail]>
> > Subject: [EXT] Re: [dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: 
> > (with DISCUSS and COMMENT)
> > 
> > APL external email warning: Verify sender [e-mail] before clicking
> > links or attachments 
> > 
> > All,
> > 
> > I think it quite reasonable for the WG to define at least one "mandatory-to-
> > implement" (i.e., NOT mandatory to use) set of security algorithms/modes for
> > BPsec — and I think it quite reasonable for the IESG to require that the WG
> > make such a choice.
> > 
> > The IETF has at least 30 years of experience that if at least one “mandatory-
> > to-implement” security profile is NOT required/specified, then non-
> > interoperability is the actual result.  In this case, non-interoperability
> > would mean that two different systems who DO wish to use BPsec between
> > themselves actually cannot use it — because of disjoint algorithms/modes
> > having been implemented in the different implementations.
> > 
> > I’m not terribly particular about which algorithms/modes the WG picks,
> > although choosing algorithms/modes readily available in open-source libraries
> > (for example: the OpenSSL library) does simplify life for implementers.
> > 
> > Yours,
> > 
> > Ran
> > 
> > > On Feb 11, 2020, at 11:37, Mehmet Adalier <[e-mail]> wrote:
> > > 
> > > While it is possible to find such a minimal requirement, I do not believe
> > > that one is required at the BPsec protocol level.
> > > I'd also like to recommend that the BPsec RFC does not specify a "minimum"
> > > interoperability context.
> > > 
> > > Depending on the use-case, interoperable contexts can be defined as other
> > > specifications. 
> > > 
> > > An example is appropriate CCSDS books which indicate interoperable contexts.
> > > . Another example is the International Communication System Interoperability
> > > Standards (ICSIS).
> > > 
> > > Mehmet
> > > 
> > > 
> > > On 2/11/20, 4:04 AM, "dtn on behalf of Mirja Kuehlewind" <
> > > [e-mail] on behalf of [e-mail]> wrote:
> > > 
> > >    Hi Ed,
> > > 
> > >    Thanks for the new text section 9.1. Reading this text I would to confirm
> > > one more thing: I understand that the best choice for the security context
> > > can be very different, however, the point of interoperability is to have at
> > > least one available, that might not be optimal but it better than none.
> > > Having one common security context required would also simply mean that each
> > > implementation would need to support that and therefore it becomes much
> > > easier for people to reply BPSec if the provided one is suitable. Is it not
> > > possible to find such a minimal requirement?
> > > 
> > >    Mirja
> > > 
> > > 
> > > 
> > > > On 8. Feb 2020, at 01:23, Birrane, Edward J. <[e-mail]>
> > > > wrote:
> > > > 
> > > > Mirja,
> > > > 
> > > > Thank you for the review. I have updated a new version of BPSEC  (BPSEC20)
> > > > which attempts to address your DISCUSS and COMMENTS below.
> > > > 
> > > > Specific comments are in-line below.  I have enumerated the Discuss items
> > > > as **D# and the comment items as **C# to aid in referencing these points
> > > > going forward.
> > > > 
> > > > -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: Mirja Kühlewind via Datatracker <[e-mail]>
> > > > > Sent: Monday, February 03, 2020 6:17 AM
> > > > > To: The IESG <[e-mail]>
> > > > > Cc: [e-mail]; Scott Burleigh 
> > > > > <[e-mail]>; [e-mail]; 
> > > > > [e-mail]; [e-mail]
> > > > > Subject: [EXT] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: 
> > > > > (with DISCUSS and COMMENT)
> > > > > 
> > > > > APL external email warning: Verify sender [e-mail] before 
> > > > > clicking links or attachments
> > > > > 
> > > > > Mirja Kühlewind has entered the following ballot position for
> > > > > draft-ietf-dtn-bpsec-18: Discuss
> > > > > 
> > > > > When responding, please keep the subject line intact and reply to 
> > > > > all email addresses included in the To and CC lines. (Feel free to 
> > > > > cut this introductory paragraph, however.)
> > > > > 
> > > > > 
> > > > > Please refer to 
> > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > > 
> > > > > 
> > > > > The document, along with other ballot positions, can be found here:
> > > > > https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/
> > > > > 
> > > > > 
> > > > > 
> > > > > --------------------------------------------------------------------
> > > > > --
> > > > > DISCUSS:
> > > > > --------------------------------------------------------------------
> > > > > --
> > > > > 
> > > > > Sec 1.2 says:
> > > > > "A sample security
> > > > >  context has been defined ([I-D.ietf-dtn-bpsec-interop-sc]) to 
> > > > > support  interoperability testing and serve as an exemplar for how 
> > > > > security  contexts should be defined for this specification."
> > > > > However I don't really understand how interoperability can be 
> > > > > reached if there is not at least one security context that is 
> > > > > mandatory to implement in this draft (especially as 
> > > > > ietf-dtn-bpsec-interop-sc is expired for more than half a year
> > > > > already)...?
> > > > 
> > > > **D1: I have added a new Section 9.1 to BPSEC20 which describes the
> > > > desired approach to BPSec and security contexts.  I have also updated
> > > > ietf-dtn-bpsec-interop-sc which should be going into WG last call.
> > > > 
> > > > > 
> > > > > --------------------------------------------------------------------
> > > > > --
> > > > > COMMENT:
> > > > > --------------------------------------------------------------------
> > > > > --
> > > > > 
> > > > > Please use the updated disclaimer in rfc8174.
> > > > > 
> > > > 
> > > > **C1: Agreed. The disclaimer has been updated in BPSEC20.
> > > > 
> > > > -Ed
> > > > 
> > > 
> > >    _______________________________________________
> > >    dtn mailing list
> > >    [e-mail]
> > >    https://www.ietf.org/mailman/listinfo/dtn
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > dtn mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dtn
> > 
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
>