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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 03 Feb 2020 03:17:12 -0800

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)...?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please use the updated disclaimer in rfc8174.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sat, 8 Feb 2020 00:23:36 +0000

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 <[email-masked]>
> Sent: Monday, February 03, 2020 6:17 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Scott Burleigh
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: [EXT] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: (with
> DISCUSS and COMMENT)
> 
> APL external email warning: Verify sender [email-masked] before clicking
> links or attachments
> 
> 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.)
> 
> 
> 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.

**C1: Agreed. The disclaimer has been updated in BPSEC20.

-Ed

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 11 Feb 2020 13:04:25 +0100

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. <[email-masked]> wrote:
> 
> Mirja,
>

---

From: Mehmet Adalier <[email-masked]>
Date: Tue, 11 Feb 2020 08:37:09 -0800

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Ed,

    Mirja

    > **C1: Agreed. The disclaimer has been updated in BPSEC20.
    
    _______________________________________________
    dtn mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dtn

---

From: Mehmet Adalier <[email-masked]>
Date: Tue, 11 Feb 2020 08:37:09 -0800

Mehmet

    Hi Ed,

    Mirja

---

From: "R. Atkinson" <[email-masked]>
Date: Thu, 13 Feb 2020 17:16:30 -0500

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 <[email-masked]> wrote:
>

---

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 17 Feb 2020 04:17:47 +0000

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

Principal Staff, Space Exploration Sector

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of R. Atkinson
Sent: Thursday, February 13, 2020 5:17 PM
To: DTN WG <[email-masked]>
Cc: The IESG <[email-masked]>
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 [email-masked] before clicking links or attachments 

All,

Yours,

Ran

>> Embedded Applications Group Supervisor Space Exploration Sector Johns 
>> Hopkins Applied Physics Laboratory
>>> Subject: [EXT] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: 
>>> (with DISCUSS and COMMENT)
>>> 
>>> APL external email warning: Verify sender [email-masked] before 
>>> clicking links or attachments
>>> 
>>> 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
>>>  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)...?
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Feb 2020 09:18:43 +0000

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:
> 1. Take the current bpsec interoperability security contexts document (draft-
> ietf-dtn-bpsec-interop-sc) and make it a normative reference in bpsec.
> 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
> 
> > While it is possible to find such a minimal requirement, I do not believe
> > that one is required at the BPsec protocol level.
> > 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" <
> > [email-masked] on behalf of [email-masked]> 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
> > 
> > 
> > 
> > > 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
> > > 
> > > ---
> > > **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.
> > > 
> > > > 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 17 Feb 2020 14:37:03 +0100

Having a normative reference would address my discuss. However given that draft-ietf-dtn-bpsec-interop-sc is short, may I ask to consider merging the two docs? I know that means a bit of delay as we would probably need to redo some of the last calls, however, if there is no specific rush, maybe these few extra weeks are not such a big issue?

Mirja

> On 17. Feb 2020, at 10:18, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Feb 2020 13:57:01 +0000

On Mon, 2020-02-17 at 14:37 +0100, Mirja Kuehlewind wrote:
> Having a normative reference would address my discuss. However given that
> draft-ietf-dtn-bpsec-interop-sc is short, may I ask to consider merging the
> two docs? I know that means a bit of delay as we would probably need to redo
> some of the last calls, however, if there is no specific rush, maybe these few
> extra weeks are not such a big issue?

I quite strongly opose merging this type of documents. There will come a time
when one like to replace the set of ciphers that are MTI. Being able to only
update that aspect by revising this particular document, rather than opening up
the whole of BPSec is an advantage. 

Cheers

Magnus Westerlund

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 17 Feb 2020 15:01:43 +0100

Okay, that's a good point...

> On 17. Feb 2020, at 14:57, Magnus Westerlund <[email-masked]> wrote:
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 17 Feb 2020 14:57:08 +0000

Hi Both,

The considered consensus of the WG was to keep the documents split for
that exact reason.

Cheers,

Rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 22 Feb 2020 18:08:00 -0800

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