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

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 17 February 2020 13:37 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEEE120122; Mon, 17 Feb 2020 05:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un7pNs8tlJ9B; Mon, 17 Feb 2020 05:37:21 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9621112013C; Mon, 17 Feb 2020 05:37:20 -0800 (PST)
Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3ga8-0004GZ-PA; Mon, 17 Feb 2020 14:37:04 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <5d83b0a4e94e1aba828699fa2b87f8ca6676269d.camel@ericsson.com>
Date: Mon, 17 Feb 2020 14:37:03 +0100
Cc: "rja.lists@gmail.com" <rja.lists@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>, "Edward.Birrane@jhuapl.edu" <Edward.Birrane@jhuapl.edu>, "rdd@cert.org" <rdd@cert.org>, "iesg@ietf.org" <iesg@ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCE92DC7-F2AE-4E0B-9F84-65FE2F270295@kuehlewind.net>
References: <158072863257.28637.8806505241822600245.idtracker@ietfa.amsl.com> <035730f96e28463a8141b026079bf3c3@aplex01.dom1.jhuapl.edu> <DE73788D-7E72-4246-B996-7F79AC805B87@kuehlewind.net> <820D95D0-F645-4551-9AE8-D30E49A2DD0E@antarateknik.com> <8A9F9AE8-18B3-4218-B8F5-D248BA4DF221@gmail.com> <b9f6e1d5c32541658059d09caa5af0fc@aplex01.dom1.jhuapl.edu> <5d83b0a4e94e1aba828699fa2b87f8ca6676269d.camel@ericsson.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581946641;6da50466;
X-HE-SMSGID: 1j3ga8-0004GZ-PA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/Hcn2YpzFxH7JUBsq6Dzj4jT4uf0>
Subject: Re: [dtn] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-d?= =?utf-8?q?tn-bpsec-18=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2020 13:37:24 -0000

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=40ericsson.com@dmarc.ietf.org> 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 <dtn-bounces@ietf.org> On Behalf Of R. Atkinson
>> Sent: Thursday, February 13, 2020 5:17 PM
>> To: DTN WG <dtn@ietf.org>
>> Cc: The IESG <iesg@ietf.org>
>> 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 dtn-bounces@ietf.org 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 <madalier@antarateknik.com> 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" <
>>> dtn-bounces@ietf.org on behalf of ietf@kuehlewind.net> 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. <Edward.Birrane@jhuapl.edu>
>>>> 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 <noreply@ietf.org>
>>>>> Sent: Monday, February 03, 2020 6:17 AM
>>>>> To: The IESG <iesg@ietf.org>
>>>>> Cc: draft-ietf-dtn-bpsec@ietf.org; Scott Burleigh 
>>>>> <Scott.C.Burleigh@jpl.nasa.gov>ov>; dtn-chairs@ietf.org; 
>>>>> Scott.C.Burleigh@jpl.nasa.gov; dtn@ietf.org
>>>>> Subject: [EXT] Mirja Kühlewind's Discuss on draft-ietf-dtn-bpsec-18: 
>>>>> (with DISCUSS and COMMENT)
>>>>> 
>>>>> APL external email warning: Verify sender noreply@ietf.org 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
>>>   dtn@ietf.org
>>>   https://www.ietf.org/mailman/listinfo/dtn
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dtn mailing list
>>> dtn@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dtn
>> 
>> _______________________________________________
>> dtn mailing list
>> dtn@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtn
>> _______________________________________________
>> dtn mailing list
>> dtn@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtn
> -- 
> Cheers
> 
> Magnus Westerlund 
> 
> 
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
>