Re: [dtn-security] bundle security protocol changes...

[Stephen Farrell <[e-mail]>]

Hi Mike,

Michael Demmer wrote:
>>- Allow a header to follow the payload in order to carry
>>signatures and MACs. I think the easiest way to do that
>>is to just let it be defined per ciphersuite, so that e.g.
>>HMAC-in-front would be a different ciphersuite from
>>HMAC-at-the-end (which would require two BAH/PSH headers
>>in the bundle). Security result is therefore also
>>optional in an ASH and we add a bit to indicate its
>>presence.
> 
> Can you briefly explain why two BAH/PSH headers are required for the
> case where the sig/MAC follows the payload. This may be obvious but I
> don't get it.

So the ciphersuite is up-front, so a node with only small buffers can
still handle large bundles. Using the same header type before and
after is just one possible design, but seems simplest to me given
the way we'll be mixing multiple applications of security headers
later on.

> Also, just so we're on the same page, the rational for having the sig
> at the end is that you can start sending the payload bits before
> you've calculated the signature on the whole thing? As such you don't
> need to pull the whole payload into memory, generate the MAC, then
> send the MAC and send the payload?

Yes, exactly. Its for nodes with small buffers who handle large
bundles (or where scaling creates the same effect).

>>- Define a type for this header since its no longer
>>in the bundle spec. I guess '2' is fine? I don't think
>>an ASH needs an overall length since the flags and
>>thereafter individual optional fields each specify
>>their own lengths.
> 
> 
> But for implementations that don't include the security support, we
> need these headers to follow the standard header preamble (with
> length) so they can be skipped when processing the bundle.

Very true. And I'd forgotten about it. (Susan had also pointed
out that we need three different header values for BAH, PSH and CH
too.) Thanks for catching that.

[...]

> For the above points, I'm too far removed to understand all of what
> you're proposing to even begin to comment :)

Yep they're just abbreviated notes. Basically though what we want to
be able to eventually support is something a bit like a mixture of
s/mime's ability to forward encrypted mail adding a new signature
and a sequence of VPN tunnels. Clearly some ascii-art is needed.

Stephen.