Re: [dtn-security] comments on security draft 01

[Stephen Farrell <[e-mail]>]

Thanks for those comments, its great to start seeing feedback
on this finally!

We might get back to you on the detailed ones when we're editing
the document, but they look fine at first glance.

Couple of remarks inline below though,
Cheers,
Stephen.

Mooi Choo Chuah wrote:
> Dear all,
> Susan encouraged me to send these comments to all so that others can 
> respond too. I already got some answers from her.
>  
> Mooi Choo
> ==========================================
>  
> Hi Susan,
> here are the comments/questions Walter and I have on your security draft 01.
>  
> 1. pg 5, 3rd line BN4 not BPA4.
>  
> 2, pg 7: header processing flags - I think a clear definition (even if 
> this is not finalized) of the different flags will be helpful to the 
> readers.
>  
> 3. pg 9: an example of when the two instances: an "up front" BAH 
> instance containing ciphersuite and another that contains security 
> result will be used will be helpful.
> The correlator field is not well explained. Again, an example will help.
>  
> 4. pg 12: The sentence "Subsequent CH security results will contain 
> headers encrypted using the BEK if non-payload headers are to be 
> encrypted" needs to be expanded with an example.
> Can we include an ASCII version of the slide that we have exchanged in 
> the document? I think it will help to clarify this. We can put this in 
> the Appendix. It will help the readers understand certain sentences.
>  
> 5.  pg 13: The sentence "This would result in uses of PSH which 
> presumably all protect the payload, and which cannot in general protect 
> one another" is confusing. An example explaining this will be helpful.
> 6. pg 22 - explain more about mulitple security results embedded in the 
> payload)
>  
> Also, explain more about what you meant by "the bundle MUST be 
> fragmented immediately after the last security result value in the 
> partial payload that is received".
>  
> Say I have an original bundle that has CH and PSH invoked. The encrypted 
> payload is 1000 bytes but I only manage to transmit 230 bytes out (the 
> 1st fragment has the CH and PSH as drawn in the slide we exchanged). 
> Then, what do I do with the 2nd fragment that I sent out? Do I include 
> just the BAH (if it is invoked) and the remaining 770 bytes of encrypted 
> payload?

I think you'd have to include the CH again - the receiver might have
forgotten the BEK or the bundle may take a different route. But this
will only work for some ciphersuites. I think we can support it with
the current one, but we have to change to a counter-mode mode of
operation, CBC mode would only work if the same decryptor maintains
internal crypto state and no API that I know of allows that. Certainly
nothing with a FIPS 1402-2 label anyway.

> also, although it may be obvious, I think it will help if we say we 
> treat custody transfer ack the same as regular bundle - meaning if 
> security feature is invoked, it will apply to custody transfer too.

If you're saying that a node can use CH and/or PSH to secure a
bundle who's content is administrative, then yes, absolutely.

If OTOH, you're saying that all custody acks must have a PSH, or
even that custody acks must be "as well protected" as the bundles
they are acking, then I'd disagree. One could write up yet
another document describing reasonable scenarios along those lines,
but I don't think there's anything normative we can add right now.
(Yes, this is part of my overall rant about not liking the
reporting stuff in the bundle protocol, but I guess that argument's
done already;-)