Subject: Re: [Gen-art] RE: Gen-Art Review: draft-ietf-msec-newtype-keyid-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Feb 2006 11:36:23 +0100

I'm a bit confused. The version on the IESG agenda this week is -03,
but you attached -04 on January 27. Which should we be looking at?

    Brian

Karl Norrman (KI/EAB) wrote:
> Hello!
> 
> Thank you very much for your review.
> Please see the attached updated draft and inline.
> 
> [SNIP]
> 
> 
>>Summary:
>>[I understand from Laksminath Dondeti that this draft maybe 
>>withdrawn, but FWIW, here is my review.] This document has 
>>some minor issues with the IANA considerations and needs some 
>>editorial tidying up.
>>
>>The 'empty map' option worries me, but I am not sufficiently 
>>much of security expert to determine if this is justified.  
>>If this is cleared the draft could go forward (but it sounds 
>>like there will be another revision pass to go through).
>>
>>Detailed Review:
>>
>>Issues:
>>I am not sure that I fully understand what is going on the 
>>justification of the need for an empty map(last para of s2).  
>>'... required parameters are signalled in-band.' => in what protocol?
>>I think a slightly less opaque explanation would help here.
> 
> 
> An example is now given (the OMA DRM Content Format used for download).
> 
> 
>>Associated with this there should be an explicit statement in 
>>s4 that no equivalent of SRTP_ID would be needed in this case.
> 
> 
> Such a statement is now added (Please note that there is a new Section
> 3, so
> this text is now in Section 5).
> 
> 
>>IANA considerations:
>>This section should refer to the IANA process setup in 
>>RFC3380 for the payload type and the CS ID map type.
>>It needs to define a new process for the Key ID Type registry.
> 
> 
> A process is now set up in the IANA considerations section.
> 
> 
>>Security Considerations:
>>Are those that understand these things absolutely convinced 
>>that creating keys without attaching them to an SA in the 
>>process does not create some sort of opportunity to create mayhem?
> 
> 
> The security considerations section is now expanded.
> 
> 
>>Editorial Nits
>>
>>You should run idnits: there are non ascii characters in the 
>>document, e.g. bullet point marks in s2.
> 
> 
> This version passed idnits.
> 
> Thanks and regards,
> Karl
> 
> 
>>s1: 3rd para: s/possibility/ability/
>>s1: 3rd para: (I take it that we are trying to make it easier 
>>rather than more difficult) s/should be/would be/
>>s1: 4th para: s/involved/keys/keys involved/
>>s2: 1st para: s/the MBMS/MBMS/
>>s2: 2nd para: s/athree level/three level/
>>s2 10th para: s/involved keys in the/keys being carried in a/
>>s3: Tables and figures should have captions
>>s3: s/bytes/octets/ (2 places)
>>s3: last para: Actually I think (2^16 -1), but I hope I never 
>>have that many keys ;-)
>>s5: s/This memo is not foreseen to introduce security 
>>implications./It is not a anticipated that this memo will 
>>have any additional security implications beyond those 
>>already identified for the MIKEY protocol./
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Russ Housley <[email-masked]>
Date: Tue, 14 Feb 2006 11:14:11 -0500

This is my fault.  I thought -04 had already been posted, but it got 
delayed. Please look at -04.

Russ

At 05:36 AM 2/14/2006, Brian E Carpenter wrote:
>>>withdrawn, but FWIW, here is my review.] This document has some 
>>>minor issues with the IANA considerations and needs some editorial tidying up.
>>>
>>>The 'empty map' option worries me, but I am not sufficiently much 
>>>of security expert to determine if this is justified.
>>>If this is cleared the draft could go forward (but it sounds like 
>>>there will be another revision pass to go through).
>>>
>>>Detailed Review:
>>>
>>>Issues:
>>>Associated with this there should be an explicit statement in s4 
>>>that no equivalent of SRTP_ID would be needed in this case.
>>
>>>This section should refer to the IANA process setup in RFC3380 for 
>>>the payload type and the CS ID map type.
>>>Are those that understand these things absolutely convinced that 
>>>creating keys without attaching them to an SA in the process does 
>>>not create some sort of opportunity to create mayhem?
>>
>>>s3: last para: Actually I think (2^16 -1), but I hope I never have 
>>>that many keys ;-)
>>>implications./It is not a anticipated that this memo will have any 
>>>additional security implications beyond those already identified 
>>>for the MIKEY protocol./
>>