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

[Lakshminath Dondeti <[e-mail]>]

At 05:36 AM 2/16/2006, Elwyn Davies wrote:
>Hi, Laksminath.
>
>
>On 16/02/06, Lakshminath Dondeti 
><<mailto:[e-mail]>[e-mail]> 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.
>
>
>The point is that the increased network resource cost is equated to 
>an increased purchase cost.  The latter is not in the standard's 
>control.  All the standard can do provide mechanisms that allow the 
>operator to make the network cost of the undesired option 
>sufficiently large that the operator can price the desired option at 
>a point where a sufficiently large fraction of potential users of 
>the service go down the paying route because the alternative is more painful.

Hi Elwyn,

This discussion could go on without end :-).  Your version is also 
fine with me.  (I will just note that we had this discussion in MSEC.)

best,
Lakshminath

>
>Regards,
>Elwyn
>
>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