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

[Stephen Farrell <[e-mail]>]

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.

S.

PS: If Peter doesn't have time, I can probably take a stab at
this.

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
>>
>