[IETF-IDRM] [IDRM] draft-irtf-smug-subsetdifference-00.txt

[Mark Baugher]

Jeff, Dalit
     I think 
http://search.ietf.org/internet-drafts/draft-irtf-smug-subsetdifference-00.txt 
is a very important draft on key revocation.  Thanks for submitting 
it.  Anyone considering LKH or a similar type of algorithm should study 
subset difference.  We should ask if there's any reason to use LKH or LKH+ 
given subset difference, which does not require a receiver to keep a 
history of membership changes as LKH-style algorithms do.  The only issue 
that comes to my mind is the larger amount of initial state.  I'll come 
back to that at the end of this note.

     I hope interested people take the time to read your I-D.  In addition 
to copying smug (now gsec) your draft is of interest to other groups.  It's 
of interest to the Internet Digital Rights Management research group 
because this algorithm spans both network and removable-media delivery of 
keying material, which is used in various copy protection schemes.  In 
addition to IDRM, I also am copying IETF msec, which is developing key 
management protocols that incorporate key revocation such as LKH+.

     The subset-difference I-D took me a lot of time to read compared to, 
say, LKH, and I found it necessary to also read 
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.html.  I don't think we 
need proofs in the I-D, a well-reviewed paper should suffice, but I needed 
the explanation and examples from the longer work (Revocation and Traitor 
Tracing Schemes for Stateless Receivers - 2nl.html) to understand what 
you're describing in the I-D.  If this work is to become the basis for 
standards such as a key revocation algorithm used by an MSEC key management 
protocol, it should be more accessible and self-contained, in my 
opinion.  For example, "Steiner Trees" is used in the I-D but is not 
defined; a crisp definition of how this concept is being applied would 
help.   I hope the next version of your draft can help the implementer by 
providing the detail to put the algorithm into code and validate correctness.

   I found the word "stateless" to be misleading since the first step to 
initialize a member is to install state in the form of keys.  "Static 
state" seems to be more descriptive than "stateless."  I was a bit 
mystified in the beginning in trying to understand the process of adding 
members, which is not described for good reason:  The initial tree is as 
large as it will ever be.  Every new member has a label in the tree, or one 
can be created on demand as you describe.  But the tree gets no larger, 
does it?  I am persuaded by your arguments that this inefficiency is 
probably not great since labels and keys can be dynamically generated in a 
Group Controller/Key Server.  But we do commit to more space at the 
receiver than the LKH-style key revocation.  This is the only downside I 
see at present wrt LKH.

Mark