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

[Stephen Farrell <[e-mail]>]

On 31/01/11 13:04, Elwyn Davies wrote:
> 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...

Yep. Will do that when we've the full set of comments.

> Do we also get a secdir review of this document? 

Nope. (Except sometimes by accident, but I'll let secdir folks know
not to bother if it happens again;-)

S.

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