[dtn] Fwd: BPsec -22, Section 9.1

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

Magnus,

I would gently suggest that if DTN WG combined my proposed edits below (email to DTN list August 7th) -- along with the proposed edits I offered earlier (email to DTN list July 29th w/ Subject: Re: [dtn] BPbis - mandatory BPsec) —that ought to be sufficient to resolve the ”MUST implement security" concerns.

I defer to the WG Chairs and AD for formal consensus determination, but I haven’t seen substantial objections to either of my notes referenced above.

For context, I’m the ghost author of RFC 3552 (most of the words are mine, which is acknowledged explicitly) and I’ve done IETF security work for about 3 decades now (e.g. RFC-1704, RFC-1825 thru RFC-1827, RFC-2082, et alia).

Thanks,

Ran Atkinson


> Begin forwarded message:
> 
> From: "R. Atkinson" <[e-mail]>
> Subject: BPsec -22, Section 9.1
> Date: August 7, 2020 at 09:25:55 EDT
> To: DTN WG <[e-mail]>
> 
> All,
> 
> Some belated feedback on the BPsec -22 draft follows, organised by section/page.etc.
> 
> Section 9.1, page 34, 2nd paragraph, which begins “Implementations of BPsec MUST…"
> 
> I am open to wordsmithing, but I propose to replace that one paragraph with these 3 paragraphs.  I am using separate paragraphs to talk about separate concepts primarily for readability.
> 
> PROPOSED NEW TEXT:
> 
>  "To ensure interoperability among various implementations, all BPSec implementations
>    MUST support at least the current IETF standards-track mandatory security context(s).  
>    As of this writing, that BCP mandatory security context is specified in 
>    [I-D.ietf-dtn-interop-sc], but the mandatory security context(s) might change 
>    over time in accordance with usual IETF processes.  Such changes are likely to occur
>    in future if/when flaws are discovered in the applicable cryptographic algorithms, 
>    for example.
> 
>    "Additionally, BPsec implementations need to support the security contexts which 
>     are specified and/or used by the BP networks in which they are deployed.  
> 
>   "If a node serves as a gateway amongst two or more networks, the BPSec
>     implementation at that node needs to support the union of security contexts 
>     mandated in those networks.”
> 
> REASONING:
> 
> An implementer of BPsec might or might not have any idea where his/her implementation might be deployed.  So the existing paragraph inadvertently requires an implementer to have knowledge which they very likely cannot have.
> 
> Extensive prior experience with IETF security protocols at various layers (e.g., IPsec tunnel-mode, IPsec transport-mode, TLS, routing protocol authentication) has consistently shown that at least one mandatory-to-implement security context needs to be specified.  As noted just above, an implementer might well not know where and how a BPsec implementation might be deployed in future.  So it is important to require implementation of at least one security context which will be common across all implementations.
> 
> Experience also has shown that over time the mandatory-to-implement security context will need to change.  The two most common reasons are (a) newly discovered flaw in a cryptographic algorithm (e.g., MD4, MD5, SHA) and (b) improved computational power making an existing algorithm computationally-feasible to attack (e.g., DES).
> 
> There is a practical requirement that implementations within a given network support whichever security context that network deploys and also that a gateway between networks support applicable security context(s).  However, those are not something which IETF reasonably can mandate, since an implementer can’t always know where a given BPsec implementation might be deployed in future.  IETF standards normally focus on implementations rather than on deployments.  Where IETF does focus on deployment matters, the usual approach is to publish a “Best Current Practice (BCP)” document rather than a “standard”.
> 
> 
> QUESTION:
> 
> Should we maybe avoid mandating [ID.bpsec-interop-sc] above and instead re-word the text above to say "as per the latest IETF BCP specifying mandatory-to-implement BPsec security contexts" (and then create a 1 paragraph BCP that says ID.bpsec-interop-sc is the current mandatory-to-implement security context) ??
> 
> That would have the hassle of creating an additional (BCP) document now, but would avoid the future hassle of needing to deprecate the entire BPsec RFC ONLY because some other security context became the mandatory-to-implement security context.  If the BPsec protocol is fine, then it would be nice to be able to change mandatory-to-implement security contexts WITHOUT changing the BPsec protocol specification.  This type of thing has happened in the past with other IETF security protocols.
> 
> 
> Feedback very welcome…
> 
> 
> Thanks !
> 
>