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

[Kevin Fall <[e-mail]>]

> From: Kevin Fall
> Date: March 19, 2009 12:34:45 AM PDT
> To: DTN interest <[e-mail]>
> Cc: Stephen Farrell <[e-mail]>
> Subject: 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
>> [e-mail]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
>