Subject: Re: [MSEC] MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02

From: Brian Weis <[email-masked]>
Date: Thu, 18 Dec 2008 09:45:07 -0800

[Forwarding David Black's latest email.]

From: [email-masked]
Date: December 12, 2008 2:51:14 PM PST
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>,  
<[email-masked]>
Subject: RE: MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02

David (M),

(1) AFrom [email-masked]  Thu Dec 18 09:44:47 2008
From: Brian Weis <[email-masked]>
Date: Thu, 18 Dec 2008 09:45:07 -0800
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MSEC] MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02
Sender: [email-masked]

[Forwarding David Black's latest email.]

From: [email-masked]
Date: December 12, 2008 2:51:14 PM PST
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>,  
<[email-masked]>
Subject: RE: MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02

David (M),

(1)dding the note about IVs to the end of the first paragraph
	of Section 2 is a fine thing to do, IMHO.  I would repeat
	that note at the end of the first paragraph of Section 6,
	as it is a security consideration.  Beyond these two, I
	don't see a need to add anything to Section 3.

(2) I agree with your suggestion for the first bullet in Section
	4.  That plus your plan to pick up my suggestions about
	the second bullet should suffice to clarify these bullets.

Thanks,
--David (B)

> -----Original Message-----
> From: David McGrew [mailto:[email-masked]]
> Sent: Friday, December 12, 2008 1:32 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02
>
> Hi David,
>
> thanks for the comments, more inline:
>
> On Dec 9, 2008, at 2:30 PM, [email-masked] wrote:
>
>
>> Last week, the authors of this draft asked me to take a look
>> at it.  I apologize for these comments coming slightly after
>> WG Last Call ends, and thank the authors in advance for their
>> patience in waiting for these comments.
>>
>> Overall, the draft looks good, and I think support for further
>> use of these modes is a "good thing".  I have a couple of minor
>> comments:
>>
>> (1) I would add a sentence to either Section 3 (IV formation)
>> or section 6 (Security Considerations) to the effect that the
>> security properties of these modes do not rely upon
>> unpredictability of the initial IV values (IV sequences for
>> counter modes tend to be predictable for obvious reasons).
>> On initial reading, I was concerned about potential SID
>> use of 2 octets out of an 8-octet IV, and such a sentence
>> would remove that concern.
>>
>
> Section 2, par 1 ends like this:
>
> "That is, for each key, no IV value can be used more than once. This
> restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM.
> In cryptographic terms, the IV is a nonce."
>
> Right after that, we could add: "(Note that CBC mode requires
> IVs that
> are unpredictable.  CTR, GCM, GMAC, and CCM do not have these
> restrictions.)
>
> I'm fine with adding something in Section 3 or 6 too.   In Section 3
> we could say "Neither the SID nor the SSIV fields need to be
> unpredictable.   The uniqueness requirements described above
> meet all
> of the security requirements of CTR, GCM, GMAC, and CCM modes."
>
> Wordsmithing welcome.
>
>
>>
>>
>> (2) The first two bullet items in Section 4 are not as clear
>> as they could be:
>> - It is unclear whether the first requirement applies across
>> 	all SAs, or on an SA by SA basis.
>>
>
> Good point.   I suggest something like"
>
> "For each SA for which sender identifiers are used, the GKMS
> MUST NOT
> give the same sender identifier to more than one active group
> member ... "
>
>
>>
>> - There is almost no discussion about what happens if the
>> 	SHOULD in the second bullet is not followed.
>> I think the first requirement is on an SA by SA basis (that
>> should be stated), and then the explanation of the SHOULD in
>> the second requirement can be two-fold:
>> - Avoids need to manage SIDs on a per-SA basis in not only
>> 	the GKMS, but also the senders (the latter is probably
>> 	the more important consideration).
>> - Avoids any need to change/issue SIDs when rekeying an SA.
>> Only the latter point appears to be mentioned.
>>
>>
>
> Sounds good to me.
>
> Thanks again!
>
> David
>
>
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>> [email-masked]        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>>

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec

 Adding the note about IVs to the end of the first paragraph
	of Section 2 is a fine thing to do, IMHO.  I would repeat
	that note at the end of the first paragraph of Section 6,
	as it is a security consideration.  Beyond these two, I
	don't see a need to add anything to Section 3.

(2) I agree with your suggestion for the first bullet in Section
	4.  That plus your plan to pick up my suggestions about
	the second bullet should suffice to clarify these bullets.

Thanks,
--David (B)

> -----Original Message-----
> From: David McGrew [mailto:[email-masked]]
> Sent: Friday, December 12, 2008 1:32 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02
>
> Hi David,
>
> thanks for the comments, more inline:
>
> On Dec 9, 2008, at 2:30 PM, [email-masked] wrote:
>
>
>> Last week, the authors of this draft asked me to take a look
>> at it.  I apologize for these comments coming slightly after
>> WG Last Call ends, and thank the authors in advance for their
>> patience in waiting for these comments.
>>
>> Overall, the draft looks good, and I think support for further
>> use of these modes is a "good thing".  I have a couple of minor
>> comments:
>>
>> (1) I would add a sentence to either Section 3 (IV formation)
>> or section 6 (Security Considerations) to the effect that the
>> security properties of these modes do not rely upon
>> unpredictability of the initial IV values (IV sequences for
>> counter modes tend to be predictable for obvious reasons).
>> On initial reading, I was concerned about potential SID
>> use of 2 octets out of an 8-octet IV, and such a sentence
>> would remove that concern.
>>
>
> Section 2, par 1 ends like this:
>
> "That is, for each key, no IV value can be used more than once. This
> restriction on IV usage is imposed on ESP CTR, ESP GCM, and ESP CCM.
> In cryptographic terms, the IV is a nonce."
>
> Right after that, we could add: "(Note that CBC mode requires
> IVs that
> are unpredictable.  CTR, GCM, GMAC, and CCM do not have these
> restrictions.)
>
> I'm fine with adding something in Section 3 or 6 too.   In Section 3
> we could say "Neither the SID nor the SSIV fields need to be
> unpredictable.   The uniqueness requirements described above
> meet all
> of the security requirements of CTR, GCM, GMAC, and CCM modes."
>
> Wordsmithing welcome.
>
>
>>
>>
>> (2) The first two bullet items in Section 4 are not as clear
>> as they could be:
>> - It is unclear whether the first requirement applies across
>> 	all SAs, or on an SA by SA basis.
>>
>
> Good point.   I suggest something like"
>
> "For each SA for which sender identifiers are used, the GKMS
> MUST NOT
> give the same sender identifier to more than one active group
> member ... "
>
>
>>
>> - There is almost no discussion about what happens if the
>> 	SHOULD in the second bullet is not followed.
>> I think the first requirement is on an SA by SA basis (that
>> should be stated), and then the explanation of the SHOULD in
>> the second requirement can be two-fold:
>> - Avoids need to manage SIDs on a per-SA basis in not only
>> 	the GKMS, but also the senders (the latter is probably
>> 	the more important consideration).
>> - Avoids any need to change/issue SIDs when rekeying an SA.
>> Only the latter point appears to be mentioned.
>>
>>
>
> Sounds good to me.
>
> Thanks again!
>
> David
>
>
>> Thanks,
>> --David
>> ----------------------------------------------------
>> David L. Black, Distinguished Engineer
>> EMC Corporation, 176 South St., Hopkinton, MA  01748
>> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>> [email-masked]        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>>

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
MSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/msec