Status of the TESLA for ALC/NORM I-D

Hello,

As promised, here are a few comments about the status of the
new TESLA for ALC/NORM I-D.

The new document:
http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-04.txt

...and the diff with -03:
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-msec-tesla-for-alc-norm-04.txt


Regards,


   Vincent et al.


General comments:
-----------------

The document is now considered as stable.

The whole specification turns out to be relatively complex,
essentially because:

1- it defines a working mode that is self-sufficient, instead of
    relying on several external documents to address for instance
    the bootstraping aspects.
    Of course this does not mean that all use-cases must follow
    the built-in bootstrap mode: it remains an optional feature.

2- it defines 8(!) different authentication tags.
    Besides, the compact formats require additional processing.
    Since the sender can transmit a few bits of the "interval
    index" only, the receivers need a mechanism to guess the non
    transmitted bits...

3- it specifies how to manage several key chains and to commit
    the next one with an in-band mechanism.
    Two alternative solutions could be (1) to define a single
    key chain, long enough to cover the whole session, or (2)
    to have several key chains and relying on an external
    signaling protocol to securely commit each chain.
    Our solution is probably more flexible than alternative 1,
    and does not require any external signaling protocol which
    can be an asset in some situations. But there is a price
    to pay for that (see "3.1.2.2.  Using Multiple Key Chains").
    However IMHO this complexity remains rather acceptable.

4- it defines an additional "weak" Goup MAC optional scheme
    which is an efficient way to deter some attacks.
    It does not make the specification significantly more
    complex but it needs to be implemented too...


Other opinions are welcome!


Differences between 03 and 04 versions:
---------------------------------------

Changes:
- the bootstrap information message has been significantly changed:
   * the key chain commitment is disclosed instead of a "current key".
     It makes this
   * the signature section now includes a "cryptographic function type"
     e.g. to specify that SHA-1 is used internally;
   * the various fields have been reorganized => 1 more 32 bit word;
   * added a "Single key chain mode" flag.

- added a Signature Cryptographic Function table in the IANA section.

- finished/clarified the specification of the steps performed by a
   receiver to authenticate packets ("4.2.  Authentication of Received
   Packets").

- added some text on how to initialize some sender parameters:
   "3.1.2.3.  Values of the n_tx_lastkey and n_tx_newkcc Parameters"
   and we moved here some text related to the special cases of session
   start and long periods of silence.

- added a requirement that when multiple key chains are used,
   the period during which disclosure of the last key of the
   previous key chain and the period during which disclosure of
   the commitment to the new key chain MUST NOT overlap.

- clarified when a receiver should flush its non authenticated
   packets.


Editorial:
- merge of the previous sections 2 and 3 to ease the reading
   of the doc.
- several text improvements.