[dtn-interest] Comments on RFC 6257

[Michael Noisternig <[e-mail]>]

Part (3/3) of my review: Comments on the Bundle Security Protocol document.

I consider the Bundle Security Protocol to be overly and unnecessarily 
complex in its current specification. I acknowledge the need for a BAB 
vs. PIB, but I don't see why the PCB should be so radically different 
from the PIB and not integrated with the PIB. The need for an ESB hasn't 
become clear to me. Rather than specifying a separate ciphersuite for 
each security block it would be preferable to split them into 
canonicalization & algorithms & parameters supported by a ciphersuite. 
In general, if the security processing would be modeled more akin to an 
actual encapsulation (tunneling) mechanism (yes, the Payload Block may 
still stay as is) some of the issues identified could potentially be 
avoided. I will try to express my thoughts more clearly in my comments 
below when addressing specific parts of the document.

2.1. Abstract Security Block, EID-references:
"If one or more references are present,
       flags in the ciphersuite ID field, described below, specify which."
As per RFC 5050, the EID references are preceded by a counter value. The 
document does not say what to do when there is a mismatch with the 
security EID flags. Also, it is not actually the ciphersuite ID field 
but the ciphersuite flags field.

Security-destination:
If a security-destination is present in some security block but bundle 
routers are not required to support the bundle security protocol this 
creates a routing problem. The problem would be avoided if some kind of 
tunnelling encapsulation were chosen for the security processing such 
that the security destination appears as the destination EID in the 
Primary Bundle Block.

3rd-last paragraph on the correlator field:
"This can be used to place a BAB that contains
    the ciphersuite information at the "front" of a (probably large)
    bundle, and another correlated BAB that contains the security-result
    at the "end" of the bundle."
Why is this flexibility wanted? Why isn't the result prescribed to be 
always at the end? In that case, why do we need to correlate blocks and 
not say "BAB requires a header block at the front and a trailer block at 
the end", without some correlation value.

2.2. Bundle Authentication Block:
I acknowledge the need for hop-by-hop vs. end-to-end security processing 
and I accept that a separate type be defined for hop-by-hop rather than 
end-to-end authentication, mainly for proper selection of the 
canonicalization algorithm (a next-hop destination could be selected via 
a broadcast endpoint in the PIB). But I think other than that there 
shouldn't be any discrepancies in order to minimize complexity; e.g., 
partial processing should be supported by both BAB and PIB.

"For the case using two related BAB instances, the first instance is
    as defined above, except the ciphersuite ID MUST be documented as a
    hop-by-hop authentication ciphersuite that requires two instances of
    the BAB."
What is the benefit of treating these as two separate ciphersuites? I 
think this should be covered by the canonicalization mechanism rather 
than by a separate ciphersuite, adding to unnecessary complexity.

2.3. Payload Integrity Block
Why do we need a PIB and not use a PCB with an integrity-only 
"cipher"suite? I am not convinced there is a need for both PIB and PCB. 
After all, they are end-to-end security blocks and refer to the same 
security link between source and destination. An integrated PIB+PCB 
could just as easily indicate the presence of a MAC or signature, which 
intermediate nodes may verify.

"The ciphersuite MAY process less than the entire original bundle
       payload.
Is this also supported for the BAB or not? (It doesn't seem so but it 
should be.)

"if the ciphersuite processes less than the complete, original bundle
       payload, the ciphersuite-parameters of this block MUST specify
       which bytes of the bundle payload are protected."
Does this refer to the fragment-range security-parameter or is it really 
part of the ciphersuite spec?

"The use of a generally available key is RECOMMENDED if custodial
    transfer is employed and all nodes SHOULD verify the bundle before
    accepting custody."
Why is this being recommended? Isn't the use of BABs satisfactory?

2.4. Payload Confidentiality Block:
"It is strongly RECOMMENDED that a data integrity mechanism be used in
    conjunction with confidentiality, and that encryption-only
    ciphersuites NOT be used."
One might prefer signatures over MACs. After all, what is the point of 
having PIBs when integrity should be part of PCBs?

"Fragmentation, reassembly, and custody transfer are adversely
    affected by a change in size of the payload due to ambiguity about
    what byte range of the original payload is actually in any particular
    fragment.  Ciphersuites SHOULD place any payload expansion, such as
    authentication tags (integrity check values) and any padding
    generated by a block-mode cipher, into an integrity check value item
    in the security-result field (see Section 2.6) of the confidentiality
    block."
Can this be elaborated? It is not clear what issue is being described here.

"Ciphersuites SHOULD define super-encryption such that, as well as re-
    encrypting the payload, it also protects the parameters of earlier
    encryption."
Why should this be part of the ciphersuite spec?

"Multiple related PCB instances are required if both the payload and
    PIBs and PCBs in the bundle are to be encrypted."
So where is the PCB that encrypts the payload positioned?

"In this scenario, the payload is encrypted
    using a BEK.  Several PCBs contain the BEK encrypted using different
    KEKs, one for each destination."
How do receivers know which key to take for decryption? By taking the 
"previous" key decoded?

"Any additional bytes generated as a result of encryption and/or
       authentication processing of the payload SHOULD be placed in an
       "integrity check value" field (see Section 2.6) in the security-
       result of the first PCB."
I think the PCB is poorly designed. It should support carriage of ICVs 
in a correlated block after the Payload Block just as PIBs and BABs do. 
(And then get rid of PIBs.)

2.5. Extension Security Block:
"Extension security blocks provide protection for non-payload-related
    portions of a bundle."
Why is a separate security block being defined? This is not clear.

2.6. Parameters and Result Fields:
"key-information: key material encoded or protected by the key
       management system and used to transport an ephemeral key protected
       by a long-term key.  This item is discussed further in
       Section 2.7."
I take it that ephemeral/session keys can only be updated using 
long-term keys? I.e., only using key transport and not key derivation?

3.2. Processing Order of Security Blocks:
This section includes a paragraph discussing the issue of overlapping 
security paths. In particular, it states that
"The bundle security scheme does not deal with security paths that
    overlap partially but not completely.  The security policy for a node
    MUST avoid specifying, for a bundle, a security-destination that
    causes a conflict with any existing security-destination in that
    bundle."
While obviously this should be avoided it actually is transparent to 
bundle security. In practice, if that happens, the bundle would have to 
be partially routed backwards.

3.4.1. Strict Canonicalization:
"we omit all PIB security-
    results for all PIB ciphersuites.  All security-result length fields
    are included, even though their corresponding security-result data
    fields are omitted."
Why should this be done? It prevents us from detecting tinkering with 
inner PIB security results.

3.4.2. Mutable Canonicalization:
"[Variable-length SDNVs] are canonicalized in unpacked form, as 
eight-byte fixed-width
    fields in network byte order."
What is the benefit of this?

It later states that
"Encoding does not need
       optimization since the values are never sent over the network."
But encoding also does not need access rate optimizations, so I do not 
see the point in re-encoding from SDNV to standard binary values.

3.5. Endpoint ID Confidentiality:
"If endpoint ID
    confidentiality is required, then bundle-in-bundle encapsulation can
    solve this problem in some instances."
How is this supported in the protocol?

3.6. Bundles Received from Other Nodes, 7th paragraph:
"If the bundle has one or more PIBs for which the receiving node is
    the bundle's PIB-destination... [...] Otherwise, if the PIB 
verifies, ..."
I am wondering, should this be set in plural, "If all PIBs verify, ..."?

3.8. Bundle Fragmentation and Reassembly, last paragraph:
"Note: various fragments MAY have additional security blocks added at
    this or later stages, and it is possible that correlators will
    collide.  In order to facilitate uniqueness, ciphersuites SHOULD
    include the fragment-offset of the fragment as a high-order component
    of the correlator."
Can this be elaborated?

4. Mandatory Ciphersuites:
"The BAB ciphersuite is based on shared secrets using HMAC.  The PIB
    ciphersuite is based on digital signatures using RSA with SHA-256."
I have mentioned the complexity of defining two separate ciphersuites 
(modulo canonicalization) for BAB and PIB before. In relation to this, 
why only a MAC for the former and only a signature for the latter?

4.1. BAB-HMAC:
"Strict canonicalization supports digesting of a fragment-bundle.  It
    does not permit the digesting of only a subset of the payload"
Why? I see no purpose in this restriction.

"If a forwarder wishes to apply more than one
    correlated BAB pair, then this can be done.  [...] the forwarder MUST
    insert all the "up front" BABs, and their "at back" "partners"
    (without any security-result), before canonicalizing."
As per 3.4.1., why are security-results being omitted?

4.2. PIB-RSA-SHA256:
"Because the signature field in SignedData SignatureValue is a
    security-result field, the entire key-information item MUST be placed
    in the block's security-result field, rather than security-
    parameters."
Not clear. This needs to be elaborated.

4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB:
What is "RSA" doing in the name? Shouldn't this rather be GCM? (The same 
question applies to 4.4. ESB-RSA-AES128-EXT.)

"Encryption is done using the AES algorithm in Galois/Counter Mode
    (GCM)"
I assume integrity check values are intended to be 128 bits in size. 
This seems like a lot of overhead for bandwidth-constrained networks, 
and certainly is more than needed for most security applications. On the 
other hand, GCM has the caveat of not being appropriate for small tag 
sizes. As such, I do not see GCM as a good choice for a mandatory 
ciphersuite.

Speaking of tag sizes, specifying different ciphersuites for all 
possible sizes is quite inflexible and potentially results in an 
exponential specification of ciphersuites. I think the ciphersuite 
should include a specification of admissible tag sizes.

7. Security Considerations:
"A message that fails the signature check will not be
    processed through the computationally intensive decryption pass."
Compared to a signature verification symmetric decryption is cheap 
(unless the payload is extraordinarily huge).

"Should exposure of either the source EID or the
    signerInfo be considered an interesting vulnerability, then some form
    of bundle-in-bundle encapsulation would be required as a mitigation."
Again... how to do bundle-in-bundle encapsulation?

"If a BAB ciphersuite uses digital signatures but doesn't include the
    security-destination (which for a BAB is the next host), then this
    allows the bundle to be sent to some node other than the intended
    adjacent node.  Because the BAB will still authenticate, the
    receiving node might erroneously accept and forward the bundle.  When
    asymmetric BAB ciphersuites are used, the security-destination field
    SHOULD therefore be included in the BAB."
Not sure I agree. It might be on purpose that no specific next-hop is 
being specified (e.g., when using anycast transmission to some next 
security hop, or when using broadcast transmission).