Re: [dtn] BPSec Last Call?

[Amy Alford <[e-mail]>]

I'll kick off the discussion of BPsec.  These comments are lightly edited
from a version I sent Ed before the working group meeting.  I'm not sure
what the standard is to be ready for last call.

My comments are pretty minor; the general approach of minimizing the
constraints on implementations (leaving it to later specifications to
design ciphersuites that work for different DTN use cases) makes sense.  I
also appreciate the simplification.  Implementing BSP in DTN2 left me
frustrated with the complexity that could accrue as intermediate nodes
could repeatedly add security blocks, extension blocks, and fragment the
bundle.

1) Is it really useful to make requirements about how security results or
security parameters are stored in the security blocks?  I’m tempted to
argue that this spec should provide the requirements that allow two
implementations which support disjoint sets of ciphersuites to interoperate
(to the extent that they can interoperate).  Specifying how ciphersuite
numbers are represented and defining processing order is necessary (an
implementation needs these to determine whether or not it can process
received data).  Separating out security parameters vs results and
specifying a key/value format for them is not (If I don't support the
ciphersuite, it's not going to help me in any way to be able to locate
individual parameters).



2) I think “MUST” is being overused.  I've included a laundry list of cases
below.

 -------------------

Section 7. “BPAs in the network MUST understand what security operations
they should apply to bundles.” “If a waypoint has been configured to add a
security operation to a bundle, and the received bundle already has the
security operation applied, then the receiver MUST understand what to do.“
 “understand” is a very fuzzy word.  I’d argue that an implementation that
completely fails to consider what to do in these cases still meets the
requirement, in the sense that it shows some deterministic behavior in
response to these conditions (If I wanted to be argumentative, I’d argue
that showing non-deterministic behavior in these cases also constitutes
understanding what to do.).



Section 2.3 “Therefore, security blocks MUST have their processing flags
set such that the block will be treated appropriately by non-security-aware
waypoints”  Since “appropriately” is left to the implementer, this doesn’t
constrain anything.



Section 2.4: “The security services defined in this specification MUST
provide a mechanism for identifying what cipher suite has been used to
populate a security block.” Isn’t this MUST referring to what you, the
author, are required to do, not what an implementer is required to do?  The
implementer MUST use the mechanism you’ve defined to do this.



Section 3.4: “This target MUST be uniquely and unambiguously identifiable
when processing a security block.” Same as the last one.  You go on to
define a mechanism by which they must do this, so this isn’t a constraint.



Section 4 uses a few MUSTS that are not requirements of this spec.  They
are expressing how crypto works, not a spec requirement.  I don’t know
whether those are traditionally MUSTs in RFCs.



In general, I’d look at each MUST/SHALL and consider whether it’s a
requirement for an interoperable implementation.

 ------------------------------------



3) Section 8.2.1 points out that a bundle may persist in the network long
enough that an attacker can decrypt it before it reaches the destination.
How much does it matter whether the attacker retrieves the information
before or after the recipient?  I see the expected transmission time as a
lower bound on the length of time the information is sensitive for.


4) Is the requirement about preserving payload length necessary when
fragmentation can only occur after adding security blocks that target the
payload?  Offsets within the payload are unambiguous, because they must
refer to the size of the payload post-encryption.


5) Since no integrity block can be processed until reassembly happens,
there is a potential for a malicious node to send large numbers of garbage
fragments to a node such that the fragments never reassemble.  There isn’t
any magic solution to this.  It looks like linux defines a timeout for
fragments to prevent this (once memory used for fragmentation exceeds some
level, the IP stack begins discarding all new fragments received until
fragments timing out reduce memory usage to some specified value). That
won’t work for DTN, since there is no sane timeout.


6) The end of 8.2.2 makes assertions about the security of sign+encrypt.
It is too strong a statement to say that the attacker cannot produce a
modified bundle /because/ he cannot decrypt. There are strong encryption
schemes in which an attacker can modify the ciphertext to produce a new
ciphertext which decrypts to a related plaintext (malleability).  Does
anyone on the list know what strength of encryption scheme is required to
guarantee the signature can't be substituted?  I think you can show
IND-CCA2 covers this, but someone must know this off the top of their head.


- Amy Alford

On Thu, Jul 27, 2017 at 11:45 AM, Birrane, Edward J. <
[e-mail]> wrote:

> Oops! Thanks Outlook....
>
>
> Let's try that again.
>
>
> DTNWG,
>
>
>   At the last DTNWG meeting we discussed whether BPSec draft 05 (
> https://tools.ietf.org/html/draft-ietf-dtn-bpsec-05) is ready for last
> call.
>
>
>   If you have read the draft and have comments on the current
> implementation, I ask that we use this thread to discuss them.
>
>
>   If you have not read the draft, but are interested in the security
> specification, I ask that you use this thread as a signal to read -05 and
> provide comments in this thread.
>
>
>   If you feel that the document is ready for last call, I ask that you use
> this thread to indicate that.​
>
>
> -Ed
>
>
> ---
> Edward J. Birrane, III, Ph.D.
> Embedded Applications Group Supervisor
> Space Exploration Sector
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 <(443)%20778-7423> / (F) 443-228-3839 <(443)%20228-3839>
> ------------------------------
> *From:* Birrane, Edward J.
> *Sent:* Thursday, July 27, 2017 11:42 AM
> *To:* [e-mail]
> *Subject:* BPSec Last Call?
>
>
> DTNWG,
>
>
>   At the last DTNWG meeting we discussed whether
>
>
>
> ---
> Edward J. Birrane, III, Ph.D.
> Embedded Applications Group Supervisor
> Space Exploration Sector
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 <(443)%20778-7423> / (F) 443-228-3839 <(443)%20228-3839>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>
>