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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
