Re: [dtn-interest] RG "last call" on draft-irtf-dtnrg-bundle-checksum

I also have a number of comments on this draft which I believe we can  
cover on thursday.
At a high level, the authors appear to wish to explain both the  
approach and its (comparatively
lengthy) rationale.  I believe the rationale belongs elsewhere,  
possibly in an informational
document that discusses reliability, integrity and the BP.  I believe  
this will help promote getting
the technical details through the process.

A couple of other things brought up by this draft:

should a bundle somehow indicate an app's {non}desire for error free  
bundles
need any corresponding API have the ability to specify this?
that there should possibly be a configuration flag in bundle agents  
indicating whether bundles failing integrity checks are dropped
(and/or whether the integrity check is applied at all-- note that we  
may be running in a high performance network as well).

- K

On Mar 16, 2009, at Mar 167:50 AMPDT, Stephen Farrell wrote:

>
> My comments on the first part (up to the end of section 3, I ran
> out of time since there was so much that needed comment) are
> attached. This is not ready IMO, I'd guess a couple more
> revs are needed before it'd be done.
>
> Stephen.
>
>
>
> SF comments on draft-irtf-dtnrg-checksum
>
> 20090312
>
> General
>
> #0 There are many editorial changes required. There are numerous  
> erroneous,
> imprecise or misleading statements that should be removed (examples  
> below).
> There are also many sections of text that appear to be discussing  
> "DTN history
> before checksums." While such text might be interesting for some it  
> doesn't IMO
> belong in an experimental RFC unless it is beneficial for  
> implementers (again,
> examples below). Basically what should be a useful specification is  
> sometimes
> almost a rant which is inappropriate. (In addition to my opinion on  
> this, the
> IRSG review specifically aims to ensure that the content is as  
> suitable as
> journal content, so this kind of change will be needed later anyway  
> its not
> just me being a pain)
>
> #1 I think a lot of the motivation stuff could be removed and that  
> that'd
> improve the document. Simpler/shorter is better.
>
> #2 The BSP has the concept of end-to-end-ishness where e.g. the  
> security source
> might not be the actual source. That's mainly to cater for less  
> capable nodes
> at the edges, and is probably not needed here, but worth asking  
> anyway. Are
> there any cases where it'd make sense to add a checksum in the  
> middle of a path
> or to strip one in the middle of a path?
>
> #3 A lot of the discussion about integrity only applies for accidental
> integrity violations. There should be a statement up front saying  
> that this
> draft doesn't consider deliberate integrity violations and that  
> those are
> address by other ciphersuites, e.g. in the BSP spec.
>
> #4 I'm totally unclear as to why there need to be three  
> ciphersuites.  Is
> there a real justification for anything other than min and max here?
>
> #5 origin authentication is not non-repudiation (if such exists as a  
> network
> service) as any security primer would tell you
>
> #6 MD5 is not a checksum algorithm, it is a digest alg. which is a  
> different
> beast (second pre-image resistance etc.)
>
> #7 You're probably better off removing the downref to my expired key  
> mgmt draft
> (draft-farrell-dtnrg-km) since someone starting over on that might  
> not base on
> that draft, which'd leave the eventual RFC with a bad pointer.
>
> #8 If you want to make the claim that using the PIB is problematic  
> for some
> reason, you need to justify that. Just saying "not designed  
> for." (which is
> ungrammatic as used) is not sufficient.
>
> #9 (sigh) The use of the term private key seems to indicate a lack of
> familiarity with crypto mechanisms. Public keys are used to verify  
> signatures.
> "3rd party intermediate nodes that do not possess that private  
> key..." is a
> crypto-101 error.
>
> #10 The RSA/SHA256 ciphersuite is criticised for some odd reason.  
> That adds
> nothing and should be deleted. (The sentence includes the terms  
> "excessive" and
> "disadvantageous.") If you are arguing that keyed ciphersuites are  
> not what you
> need then such points are superflous and would only serve to confuse  
> a reader.
>
> #11 What is a "NULL key pair"? As far as I'm aware this is the first  
> time
> anyone's suggested using a known key for RSA ever. (No one else has  
> becuase
> it'd be silly, a known symmetric key is similar strength and far  
> easier.) I
> don't believe anyone has ever suggested re-using an existing  
> ciphersuite with a
> known key, all previous cases invent a new ciphersuite. There is  
> really no
> point in discussing obviously silly design choices that could have  
> been made by
> someone not skilled in the art.  (Actually, just deleting that  
> entire paragraph
> is best.)
>
> #12 BAB-HMAC discussion. I'm not sure if its a good idea to opine  
> here on
> changes that "could" be made to the BP, but if that remains, it  
> should at least
> say "a future version of the BP." Noting that the BP doesn't mandate  
> the BSP is
> fine, but the future looking stuff might confuse a reader, so I'd  
> leave it out.
> Saying that some "path" seems to be desirable is also needlessly  
> confusing,
> this document should just specify and explain the new ciphersuites  
> and not be
> as argumentative.
>
> #13 Mention of your "previous proposal" adds nothing and exposes an  
> apparent
> minsunderstanding on the author's part of compliance. This spec can  
> and should
> define new PIB ciphersuites. There is no reason why conforming  
> implementations
> should also have to implement other ciphersuites as well.  (And again
> "heavyweight" is purely pejorative so remove that.)
>
> #14 The "insecure ciphersuites might give a false impression of  
> security"
> argument seems to me to be bogus. Have there ever been any cases  
> where IPsec or
> TLS equivalents were accidentally used? This could be a security  
> cconsideration
> to point out to coders that they shouldn't confuse administrators in  
> user
> interfaces, but is not a real issue in terms of the bits on the  
> wire..  (I do
> like the idea of naming these ciphersuites INSECURE or something,  
> but that
> doesn't mean there's a real issue here.)
>
> #15 "SHOULD subjective ensure" is very odd.
>
> #16 I don't follow why logging output is significant enough for a  
> MUST NOT?
>
> #17 The requirement that any future similar ciphersuite be called  
> "INSECURE" is
> broken. Just say that these ciphersuites are called that and you're  
> done. Also
> PIBs using these are not indistinguishable from those with secure  
> ciphersuites
> - that's the whole point of the ciphersuite types. You're confusing  
> the name of
> the ciphersuites (that might appear in GUIs) with the bits on the  
> wire where
> no such confusion arises.
>
> #18 You seem to contradict yourself when you say that things MUST be  
> called
> INSECURE_* but then say that PIB-HMAC with NULL keys is ok. I think  
> one or the
> other is ok, but not both. I think that PIB-HMAC if its useful (and  
> it could
> be) ought be in a different document (probably BSP) and the NULL key  
> version
> should be here as its own ciphersuite. (Or just omitted, I'm not  
> sure who wants
> PIB-HMAC-WITH-NULL?)
>
> #19 Talking about what BP implementations MUST support is missing  
> the point.
> This spec should talk about what implementations doing this spec  
> MUST support
> and not others.
>
> #20 Mutable c14n is defined in the BSP and not in appendix A.1 The  
> PIB wire
> format is defined in the BSP and not in appendix A.2. As-is, both  
> inaccurate
> statements would mislead implementers.
>
> #21 Using a zero KeyID as the indicator of a NULL ciphersuite is a bad
> choice IMO. (It should be a separate ciphersuite as explained  
> above.) The
> problem is that there are times when shared secrets are used without
> KeyIDs (which is bad practice, but happens). A zero KeyID is too easy
> for a coder to mistake as a missing KeyID so its better to either have
> the same semantic or none.
>
> #22 end of p12, I don't get what "the later two EIDs" means? Needs  
> some
> clarification I guess. (Maybe just a type s/EID/SDNV/?)
>
> #23 What makes you think an 80-bit MAC is less good at error detection
> than a (known weak) 128 bit digest? Such statements are better deleted
> (or else justified with references).
>
> #24 "Although the BSP was intended..." again the authors appear  
> confused
> about compliance - this document does not UPDATE 5050 (not sure what
> that'd mean for an experimental RFC anyway) so discussion of things
> that are "needed" by BP implementations is off base. This is even
> clearer in the next paragraph where the spec tries to impose  
> requirements
> on 5050 implementations doing custody stuff.
>
> #25 "...private keys shared only..." Private keys are never shared in
> any DTN ciphersuite. Another crypto-101 error.
>
> #26 You have a SHOULD on dropping when checks fail. What about  
> fragmentation?
>
> #27 "...end-to-end private key" crypto-101 Entire paragraphs needs  
> fixing.
>
> ------------
>
> Editorial changes in the early pages. (I stopped separatng them
> after a while since there are so many.)
>
> Abstract:
>
> #1 the BP does not include a checksum, yet it *is* possible to do  
> verification,
> if the BSP is used. The statement is misleading.
>
> #2 "Without assurance...cannot" is wrong. "may not" would be correct.
>
> #3 sometimes errored bundle forwarding is desired, suggest replacing  
> "instead
> of..." with "where it may have been better to..."`
>
> #4 "address the situation" implies that this is correcting a serious  
> unexpected
> fault which is disputed
>
> #5 "Formerly called" adds no value
>
> #6 "Regardless of" clause adds no value
>
> #7 "Divorcing" clause seems odd - I think you mean to say there's no  
> need for
> keys but I don't see any papers being served.
>
> #8 "necessary detail" why would you include unnecessary detail? delete
> necessary
>
> #9 Overall an abstrct like the following would be much better:
>
> The Delay-Tolerant Networking Bundle Protocol includes a custody  
> transfer
> mechanism to provide acknowledgements of receipt for particular  
> bundles.  The
> bundle protocol does not define a checksum that allows verification of
> error-free forwarding at any hop on the path. This document defines  
> new
> "keyless" data integrity ciphersuites for use with the Bundle Security
> Protocol's Payload Integrity Block that can be used to increase  
> reliability in
> many situations.
>
> Section 1:
>
> #0 this entire section could be deleted, or almost all
>
> #1 2nd para: "does not take bundle inegrity into account" is  
> misleading; the BP
> asssumes that CLs do that which is different.
>
> #2 something that's not always sufficient is not always insufficient  
> to talking
> about "the insufficiency" is a mistatement
>
> #3 s/painstakingly// it adds nothing but pique
>
> #4 delivering errored content does not require that "all underlying  
> layers pass
> through and accept errors", only perhaps that the layers in use when  
> the error
> occurs support that, and with bugs, memory or file system errors not  
> even that
>
> #5 the claim that the "ability to provide a check" is primary to  
> "overall
> strength" needs a reference or should be deleted
>
> #6 last para of p7:s/much more important/potentially much more  
> important/
>
> #7 same para as #6, everything from "the bundle protocol..does  
> neither..." down
> to"...Internet traffic." should be deleted. Its only purpose seems  
> to be to try
> make the bundle protocol look bad?
>
> #8 last para: delete the paragraph I guess it just vituperative,  
> hard to
> understand how it ever got added
>
> section 2:
>
> #1 there are currently 4 block types in BSP but I don't think  
> there's any need
> to discuss that, just say we're re-using PIB. There is no reason to  
> discuss
> BAB, PCB or, now ESB at all.
>
> #2 delete the sentence that says "truly suitable" - actually an  
> entire page or
> so can best be deleted here, incl. the "what's a MAC" part.
>
> #3 The "in fact, several popular" sentence gets it wrong, some  
> digest algs are
> used for MACs
>
>
> _______________________________________________
> dtn-interest mailing list
> dtn-interest@maillists.intel-research.net
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest