Subject: Re: [MSEC] GDOI Update draft

From: "Sheela Rowles (sheela)" <[email-masked]>
Date: Fri, 7 May 2010 17:21:43 -0700

Really sorry for the late response. 

See inline SR: 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Thursday, April 08, 2010 4:35 AM
To: [email-masked]
Subject: [MSEC] GDOI Update draft

Hi.

As I promised at the meeting, I will review this draft thoroughly, but I
already have two comments

1.	It was said in the meeting (although it's not written in the
draft) that none of the known implementations have implemented the PFS
extension, and so it is dropped. This is incorrect. I have checked Check
Point's implementation, and it does, in fact, implement the PFS feature.
What the draft says, in appendix B, is that it provides negligible
value, and that the specification is faulty. These statements are true.

	Much as I'd hate to deprecate running code from my own company,
I agree with the reasoning in appendix B, so I'm fine with it being
deprecated.
2.	The document is missing a conformance requirements section.
Although there is some conformance language in the various sections,
like DES is SHOULD NOT, and AES-CBC-128 is MUST, the document is missing
a centralized list of what is required, as opposed to optional, or not
recommended.  I would suggest the following:

SR: 

I like the idea of doing a conformance requirements section especially
if it helps to clarify the SHOULDs and MUSTs.   Is there an example RFC
or draft where this is done that I can take a look at?

KEK_MANAGEMENT_ALGORITHM

*	LKH - MUST  (?)

SR: "Implementation of the LKH algorithm is OPTIONAL."

KEK_ALGORITHM

*	DES - SHOULD NOT
*	3DES - SHOULD
*	AES - MUST

SIG_HASH_ALGORITHM

*	MD5 - MUST NOT
*	SHA1 - SHOULD NOT
*	SHA256 - MUST

(BTW: why do you have to specify this at all?  With RSA, you're using
the PKCS#1.5 format that encodes the hash algorithm anyways, so why
negotiate it?)

SR: By having the information in the SA payload during registration, the
GM has the opportunity to determine whether it can support the requested
algorithm and react appropriately if it doesn't support it.   Otherwise,
the GM will only recognize it can't support the requested algorithm upon
receiving the first rekey. 

SIG_ALGORITHM

*	RSA - MUST

protocol

*	ESP - MUST
*	AH - MAY

Key download type

*	are all three types mandatory?

SR: No.  The draft does not mandate that all three types are present.
LKH is optional. 

Section 5.2.1: 
   There may be zero or one SAK Payloads, zero or more GAP Payloads, and
zero or

   more SAT Payloads, where either one SAK or SAT payload MUST be

   present.

And so on.

Anyway, I do promise to read this throughly soon.

Yoav

SR: Looking forward to your full review. 

Thanks, 

Sheela

---

From: Yoav Nir <[email-masked]>
Date: Sun, 9 May 2010 09:26:46 +0300

On May 8, 2010, at 3:21 AM, Sheela Rowles (sheela) wrote:

See inline SR:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Thursday, April 08, 2010 4:35 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [MSEC] GDOI Update draft

Hi.

As I promised at the meeting, I will review this draft thoroughly, but I already have two comments

 1.  It was said in the meeting (although it's not written in the draft) that none of the known implementations have implemented the PFS extension, and so it is dropped. This is incorrect. I have checked Check Point's implementation, and it does, in fact, implement the PFS feature. What the draft says, in appendix B, is that it provides negligible value, and that the specification is faulty. These statements are true.
Much as I'd hate to deprecate running code from my own company, I agree with the reasoning in appendix B, so I'm fine with it being deprecated.
 2.  The document is missing a conformance requirements section. Although there is some conformance language in the various sections, like DES is SHOULD NOT, and AES-CBC-128 is MUST, the document is missing a centralized list of what is required, as opposed to optional, or not recommended.  I would suggest the following:

SR:

I like the idea of doing a conformance requirements section especially if it helps to clarify the SHOULDs and MUSTs.   Is there an example RFC or draft where this is done that I can take a look at?

[YN]
There's section 9 in RFC 5246 (TLS 1.2), but that is rather sparse. And there's RFC 4307 for IKE/IPsec.

KEK_MANAGEMENT_ALGORITHM

 *   LKH - MUST  (?)

SR: “Implementation of the LKH algorithm is OPTIONAL.”

KEK_ALGORITHM

 *   DES - SHOULD NOT
 *   3DES - SHOULD
 *   AES - MUST

SIG_HASH_ALGORITHM

 *   MD5 - MUST NOT
 *   SHA1 - SHOULD NOT
 *   SHA256 - MUST

(BTW: why do you have to specify this at all?  With RSA, you're using the PKCS#1.5 format that encodes the hash algorithm anyways, so why negotiate it?)

SR: By having the information in the SA payload during registration, the GM has the opportunity to determine whether it can support the requested algorithm and react appropriately if it doesn’t support it.   Otherwise, the GM will only recognize it can’t support the requested algorithm upon receiving the first rekey.

SIG_ALGORITHM

 *   RSA - MUST

protocol

 *   ESP - MUST
 *   AH - MAY

Key download type

SR: No.  The draft does not mandate that all three types are present.  LKH is optional.

Section 5.2.1:

   There may be zero or one SAK Payloads, zero or more GAP Payloads, and zero or

And so on.

Yoav

Thanks,
Sheela