[secdir] secdir review of draft-ietf-dtn-bpsec-06

[Dan Harkins <[e-mail]>]

   Hello,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

   The summary of my review is: Almost-Ready.

   This draft describes a protocol called BPSec which "provides
end-to-end integrity and confidentiality services for BP bundles."
But it doesn't really define a security protocol because it leaves
key establishment and the actual ciphers used to afford end-to-end
protection to bundles to different documents. So it's sort of like
EAP in that respect.

  1. Issues with encryption and integrity protection

   There are 2 different blocks defined, a Block Integrity Block (BIB)
that provides integrity protection and a Block Confidentiality Block
(BCB) that encrypts the block. Apparently, the BCB does not also
provide integrity protection of its ciphertext since the draft says
that, while multiple security operations on the same block are invalid,
doing integrity protection and confidentiality on the same block is
valid. This opens up some insecure options that don't need to be allowed,
like integrity protect then encrypt, or integrity protect and encrypt.
I think it would be a good idea to mandate that whatever ciphersuite
is used for a BCB (again, the draft does not specify ciphersuites) that
it provides authenticated encryption. Then update the uniqueness
requirement in section 3.2.

   The example in figure 3 does authenticate-then-encrypt which is
not robust. This needs to change.

   The processing order in 5.1 states "BCBs MUST be evaluated first
and BIBs second." This is wrong, it's mandating a fragile construct
whose security depends on the cipher mode and that is dangerous.
Strongly suggest changing this and using and AEAD cipher.

   Also in 5.1: "If an encrypted payload block cannot be decrypted...."
How would you know? As long as it's the right size it will decrypt
into something. That something might be garbage but decryption was
successful. This is another reason to mandate AEAD. If it fails, it
fails hard, no two step required.

   My suggestion to use an AEAD cipher seems to conflict somewhat with the
fragmentation/reassembly text which says that application of a
confidentiality cipher suite MUST NOT alter the size of the payload.
That is going to have to be reconciled somehow. This document should
not allow anything other than encrypt-then-authenticate (and it should
do so by mandating AEAD ciphers) and if that requires some rewrite of
the fragmentation/reassembly text then so be it.

  II. Issues with RFC 2119 words

   I hate to be a stickler on stuff like this but...

   Section 2.2 which begins, "A bundle MAY have multiple security blocks
and these blocks MAY have different security sources." Now, to me, MAY
means it's optional and that if I don't implement it I can still stay
compliant. But that's not how I'm reading this. What I'm reading
is an admonition to not assume uniformity in bundles, which seems
like an important statement that is the opposite of the literal MAY
text. It's really you MUST NOT assume that a bundle has uniform
security.

   Section 3.3: "A set of security operations may be represented by a
single security block if and only if the following conditions are true...."
That sounds kind of normative.  Do the authors mean "A set of security
operations SHALL be represented by a single security block...."?

   Regarding the optional "Security Source" in the Abstract Security Block
in section 3.6: "If the security source field is not present then the
ource MAY be inferred from other information...." And that means I can
choose to not implement this optional inference. In which case, what do
I do? I think some instruction to implementers is needed but I'm
not sure what it is.

   Basically, I think the whole document should be searched for "may" (case
insensitively) and each instance looked at closely.

   III. Security Considerations

   The security considerations are thorough and well done although the
first three paragraphs in section 8 seem to boil down to the fact that
the DTN is assumed to be completely under the control of an attacker. I
think that's all that needs to be said there.

   regards,

   Dan.