Re: [dtn] BPSec Last Call?

[[e-mail]]

bpsec isn't ready for last call, because bpbis, which it depends on,isn't ready for last call. it's that simple.
(also, the bpbis reference in this draft was out of dateeven when it was submitted.)


Lloyd WoodLloyd Wood - Delay-Tolerant Networking work
  
|  
|   
|   
|   |    |

   |

  |
|  
|   |  
Lloyd Wood - Delay-Tolerant Networking work
 

  |   |

  |

  |

 


On Wednesday, August 16, 2017, 7:26 am, Amy Alford <[e-mail]> wrote:

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/d raft-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 / (F) 443-228-3839From: 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 / (F) 443-228-3839
______________________________ _________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/l istinfo/dtn



_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn