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

From: Elwyn Davies <[email-masked]>
Date: Wed, 15 Feb 2006 23:56:54 +0000

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 15 Feb 2006 16:44:08 -0800

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:
>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 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 
>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.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Feb 2006 10:37:54 +0100

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.
> 
> 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
> 
>> tries to avoid this as we are defining purely technical standards.  I 
>> have suggested some alternative words below which reflect the purely 
>> technical approach.
>> 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.
>>
>> 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:
>>
>> 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:
>> 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:
>> 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.
>>

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 16 Feb 2006 13:36:13 +0000

Hi, Laksminath.

> 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.

Regards,
Elwyn

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 16 Feb 2006 07:54:05 -0800

At 05:36 AM 2/16/2006, Elwyn Davies wrote:
>Hi, Laksminath.
>
>
>On 16/02/06, Lakshminath Dondeti 
><<mailto:[email-masked]>[email-masked]> wrote:
>Hi Elwyn,
>
>Thanks for your review.
>
>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