Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security

[Elwyn Davies <[e-mail]>]

On Mon, 2011-01-31 at 11:14 +0000, Stephen Farrell wrote:
> I suspect that we won't get to do those before the IESG chat so
> lets see if any other ADs have useful comments and then address
> 'em then.
OK.  However I think it would be useful to think about the sign
first/encrypt first comments.  Not being a security geek I am not
qualified to offer opinions...

Do we also get a secdir review of this document? 
> 
> S.
> 
> PS: If Peter doesn't have time, I can probably take a stab at
> this.
Thanks!

/E
> 
> On 31/01/11 10:50, Elwyn Davies wrote:
> > Hi
> > 
> > Thanks to Sean for the review.  I see from the datatracker that you
> > don't think these are blocking issues.
> > 
> > Authors:  any responses to the comments?  I guess we need to fix up the
> > nits anyway.  I think Peter has the editorial pencil at the moment.. do
> > you have cycles to do the fixes?
> > 
> > Regards,
> > Elwyn
> > Document Shepherd
> > 
> > Couple of (trivial) comments in line below...
> > 
> > On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:
> > 
> >> -------- Original Message --------
> >> Subject: Nits on draft-irtf-dtnrg-bundle-security
> >> Date: Sat, 29 Jan 2011 17:23:28 -0500
> >> From: Sean Turner <[e-mail]>
> >> To: [e-mail]
> >> CC: [e-mail], The IESG <[e-mail]>
> >>
> >> Hi,
> >>
> >> Here's some comments/questions I have on this document (note this isn't
> >> my RFC 5742 review):
> >>
> >> - No 'Intended status' indicated for this document; I'm assuming
> >> Experimental as per the datatracker.  I think you should probably add
> >> the header line to make sure though.
> >>
> >> - There are two unused references: RFC 3370 and RFC 4106.
> >>
> >> I think 3370 could we worked in somewhere when describing the CMS bits.
> >>
> >> For the 4106 I think the checker is barfing on the following from
> >> Section 4.3 and 4.4:
> >>
> >> [Note: parts of the following description are borrowed from RFC 4106].
> >>
> >> Maybe replace it with:
> >>
> >> Note: parts of the following description is borrowed from [RFC4106].
> >>
> >> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
> >>
> >> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
> >> death?
> > No.  The version is out of date.  Version 06 exists.
> >>
> >> - Expand DTN, EID, SDNV, BA, and PI on first use
> >>
> >> - Authentication is mentioned for the first time in Sec 2 when
> >> discussing the PIB.  Wouldn't it be better to mention it earlier?
> >>
> >> - Section 2.1: When describing the two EIDs and cipher suite flags as
> >> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
> >>   Same for the Figure 3 description (i.e., the paragraph before the figure).
> >>
> >> - Section 2.3: r/the key information item Section 2.6 is optional, and
> >> if not provided then the key should be/the key information item Section
> >> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
> >>
> >> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
> >> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
> >> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
> >> you do this need to add "NOT RECOMMENDED" to the first para in section 1
> >> like the errata 499:
> >> http://www.rfc-editor.org/errata_search.php?rfc=2119
> >>
> >> - Section 2.4: Some "SHOULDs":
> >>
> >>     It is RECOMMENDED to apply a Payload
> >>     Confidentiality ciphersuite to non-payload blocks only if these
> >>     SHOULD be super-encrypted with the payload.  If super-encryption of
> >>     ^^^^^^
> >>     the block is not desired then protection of the block SHOULD be done
> >>                                                           ^^^^^^
> >>     using the Extension Security Block mechanism rather than PCB.
> >>
> >> - Section 2.4: "SHOULD NOT" instead of "should not":
> >>
> >>     These multiple PCB instances, are
> >>     not "related" and SHOULD NOT contain correlators.
> >>                       ^^^^^^^^^^
> >>
> >> - Section 2.8: In the paragraph about authenticated and encrypted
> >> bundles, I think the last sentence should be "RECOMMENDED".  It's
> >> interesting to note that you'd prefer encrypt then sign as opposed to
> >> sign and then encrypt.  Looking forward to the security consideration
> >> about why.
> >>
> >> - Section 3.2: r/MUST not/MUST NOT ?
> >>
> >> - Section 3.2: r/No other blocks are
> >>     required to follow the payload block and it is RECOMMENDED that they
> >>     NOT do so./No other blocks are
> >>     required to follow the payload block and it is NOT RECOMMENDED
> >>     that they do so.
> >>
> >> - Section 3.4.2: r/This algorithm is intended to protect parts of the
> >> bundle which should not be changed in-transit./This algorithm is
> >> intended to protect parts of the bundle which SHOULD NOT be changed
> >> in-transit.
> >>
> >> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
> >>
> >> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
> >> id-data, but you should probably be explicit about it.
> >>
> >> - Section 4.1: r/Security parameters are optional with this
> >> scheme/Security parameters are OPTIONAL with this scheme
> >>
> >> - Section 4.1: A couple of comments/questions on the following:
> >>
> >>     Implementations MUST support use of "AuthenticatedData" type as
> >>     defined in [RFC5652] section 9.1, with RecipientInfo type
> >>     KeyTransRecipientInfo containing the issuer and serial number of a
> >>     suitable certificate.  They MAY support additional RecipientInfo
> >>     types.  They MAY additionally use the "SignedData" type described in
> >>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
> >>     EncapsulatedContentInfo contains the encrypted HMAC key.
> >>
> >> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
> >> reason you chose differently?  Most certificates have SKIs (now) and
> >> it's probably smaller than the issuer/serial # combo.
> >>
> >> 2. How is SignedData used here?  It says it MAY be used - is that in
> >> addition to?  There's no RecipientInfo with SignedData so I am a little
> >> confused.
> >>
> >> - Section 4.1 and 4.2: Should probably say something about whether you'd
> >> recommend no unsigned/unauthenticated and signed/authenticated
> >> attributes.  I'm assuming you're not recommending any ;)
> >>
> >> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
> >> issuer/serial # combo.  Any reason you chose differently?  Most
> >> certificates have SKIs and it's probably smaller than the issuer/serial
> >> # combo.
> >>
> >> - Section 4.2: Had the following:
> >>
> >>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
> >>    signature scheme in [RFC4055].
> >>
> >> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
> >> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
> >> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
> >> like what's the hashAlgorithm, maskGenAlgorithm, whether
> >> RSASSA-PSS-params is included in certificates?
> >>
> >> Also r/RSA with SHA256/RSA with SHA-256
> >>
> >> - Sections 4.1-4.4: The eContent values for the CMS content types threw
> >> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
> >> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
> >> reads like there are two sets of operation for each of the four Block
> >> Types.  You do one for the BAB, PIB, etc. values and then another for
> >> the CMS structures?  Am I reading that right?  The parts about the
> >> "eContent" e.g.,:
> >>
> >> The "eContent" field in EncapsulatedContentInfo contains the signed
> >> checksum (SignatureValue) of the data.
> >>
> >> That tells me the CMS processing generates a message digest over the PIB
> >> SignatureValue and then signs the output of the message digest and put
> >> it in the SignerInfo.signature value field.
> >>
> >> Couldn't you just omit all the eContents?  They're optional in all cases
> >> and can be gotten from elsewhere in the CMS blobs.
> >>
> >> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
> >> considerations when using CMS/certificates.  This save you recreating
> >> text about keeping keys secret, etc.  Need some additional motherhood
> >> and apple pie statements about randomly generating keys and point to
> >> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
> >>
> >> - Section 7: I didn't see a security consideration that addresses why
> >> you'd prefer to encrypt then authenticate.  The text earlier implied and
> >> attack of some kind.  RFC 5751 also had something to say about this:
> >>
> >>     There are security ramifications to choosing whether to sign first or
> >>     encrypt first.  A recipient of a message that is encrypted and then
> >>     signed can validate that the encrypted block was unaltered, but
> >>     cannot determine any relationship between the signer and the
> >>     unencrypted contents of the message.  A recipient of a message that
> >>     is signed then encrypted can assume that the signed message itself
> >>     has not been altered, but that a careful attacker could have changed
> >>     the unauthenticated portions of the encrypted message.
> >>
> > (The following comment was withdrawn.. all new ones have 'specification
> > required' quoted.)
> >> - IANA Considerations: When defining an IANA controlled registry the
> >> document needs to indicate how the registry is updated (e.g., RFC
> >> required, expert review, etc.).  See Section 4 of RFC 5226.
> >>
> >> Cheers,
> >>
> >> spt
> >>
> > 
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest