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

[Brian E Carpenter <[e-mail]>]

Since it looks like a new version anyway, I will be No Objection
and just point to this thread.

    Brian


Lakshminath Dondeti wrote:
> Hi Elwyn,
> 
> Thanks for your review.
> 
> I interpret the word "cost" as cost of an attack, which is a perfectly 
> acceptable term in analyzing security properties of a protocol or a 
> mechanism.  Your wording is also fine.  I don't have strong feelings 
> either way.
> 
> GMARCH is a typo and should be GKMARCH for Group key management 
> architecture (RFC 4046).
> 
> Sam has a DISCUSS on this.  The discussion so far indicates that we'll 
> need an -05-.  I will ask Karl et. al. to wait until after the IESG 
> telecon is over (Thursday morning ET?) before starting revisions on this.
> 
> thanks and regards,
> Lakshminath
> 
> At 03:56 PM 2/15/2006, Elwyn Davies wrote:
> 
>> Background for those on the CC list, who may be unaware of GenART:
>> GenART is the Area Review Team for the General Area of the IETF.  We
>> advise the General Area Director (i.e. the IETF/IESG chair) by providing
>> more in depth reviews than he could do himself of documents that come up
>> for final decision in IESG telechat.  I was selected as the GenART
>> member to review this document.  Below is my review, which was written
>> specifically with an eye to the GenART process, but since I believe that
>> it will be useful to have these comments more widely distributed, others
>> outside the GenART group are being copied.
>>
>> Document: draft-ietf-msec-newtype-keyid-04.txt
>> Intended Status: Proposed Standard
>> Shepherding AD: Russ Housely
>> Review Trigger: IESG Telechat 16 February 2006
>>
>> Summary:
>> This document is in much better shape than when I reviewed v01 for 
>> IETF LC. There are a couple of points which I think still need 
>> clarification before it is quite ready for PS:
>>
>> - In s1 the rationale talks about money costs: the IETF generally 
>> tries to avoid this as we are defining purely technical standards.  I 
>> have suggested some alternative words below which reflect the purely 
>> technical approach.
>> - There are some rather vague words in the start of the security 
>> considerations that lead one to wonder if the security considerations 
>> are incomplete.  It is entirely possible that this is merely 
>> inappropriate English but this needs editing.
>>
>> There are also a couple of editorial nits which can be fixed during 
>> copy editing  if more substantial changes are not to be made.
>>
>> Detailed Review:
>>
>> Issues:
>>
>> s1, para 3: I misunderstood what this was trying to say in v01.  I can 
>> now discern the intent but it needs some tuning.  In line with normal 
>> IETF practice we should specify a technical proposal which will 
>> achieve a business aim rather than actually specifying the business 
>> behaviour:
>>
>>>  The rationale behind this is
>>>    that it will be costly for subscribers to re-distribute the
>>>    decryption keys to non-subscribers. The cost for re-distributing the
>>>    keys using the unicast channel should be higher than the cost of
>>>    purchasing the keys for this scheme to have an effect.
>>
>> How about:
>>  The rationale behind this is that it should be made substantially 
>> more inconvenient for subscribers to re-distribute the decryption keys 
>> to non-subscribers as compared with the non-subscribers becoming 
>> subscribers in order to acquire these keys. In order for this scheme 
>> to induce this behavior, the impact of the effort required to 
>> re-distribute the keys using separate unicast channels should 
>> therefore be sufficiently high that it will not be worthwhile for 
>> potential users of the service to access the content without subscribing.
>>
>> Security Considerations:
>> s6, para 1: The phrase 'there are mainly two points...' sounds 
>> dangerous when it appears in Security Considerations.  Is this 
>> supposed to mean there are (exactly) two  points? If not, are there 
>> others which you don't tell us about: we need to know so we can check 
>> they aren't significant or alternatively they might not be about 
>> security, in which you might write 'There are two main points which 
>> affect the security considerations.'
>>
>> Editorial Nits:
>> s2, last para: s/to the "empty map"/for the "empty map"/
>>
>> s3: The acronym GMARCH is not defined and is only used in the section 
>> title.  I take it is something about Group key Management ARCHitecture 
>> but it doesn't seem to be in general usage.
>>
>> s3, title: s/Relations/Relationship/
>>
>> s6, para 1: s/designed./designed to be used./
>>
>> s6: Acronyms not expanded: MAC, TESLA.
>>
>> s6, para 2: s/is not compatible with/is not appropriate for use with/
>>
>>
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 


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