[Rmt] Comments on TESLA source authentication in the ALC and NORM protocols: draft-faurite-rmt-tesla-for-alc-norm-00.txt

["Michael Luby" <[e-mail]>]

Comments on TESLA source authentication in the ALC and NORM protocols:
draft-faurite-rmt-tesla-for-alc-norm-00.txt

First off, I think that this is a very good thing to try and standardize, as
TESLA is ideally suited to provide authentication and packet integrity
protection to ALC and NORM.   Unfortunately, I have a lot of questions and
issues with the draft, and some are basic questions about where this work
should be done.

What I was expecting is a document that describes how to apply TESLA and
related security features that have been developed in MSEC that have been
developed in the spirit of a building block to ALC and NORM, where all the
security issues have been addressed in the TESLA work and it is simply cut
and paste to put that into the ALC and NORM context.  What I see instead is
a document that describes a lot of protocol work that has security aspects
to it that seems more suitable for MSEC.  I’m not sure why this is, perhaps
because the TESLA specification does not lend itself to being used as a
building block directly, and perhaps because some of the other security
protocols have not been addressed by MSEC.  It would be good though if the
basic security work were done in MSEC, and only applications of that work
that have no potential to introduce weaknesses in security were described in
the RMT work that describes how these protocols are applied to ALC and NORM.
I have been informed that this is the approach taken with SRTP, i.e., the
work to apply TESLA to SRTP is being done within MSEC, and not AVT.

As an example, Section 2 describes protocols for time synchronization
between the sender and receivers.  Since the security of TESLA entirely
relies on time synchronization, the security of this protocol is of crucial
importance.  Furthermore, it seems that time synchronization would be a
basic primitive of any protocol that uses TESLA.  Thus, it seems like the
time synchronization protocols should be work done within the MSEC group
that can then be leveraged for application work done in RMT, and it seems
inappropriate for this work to be done in RMT since the security protocol
experts aren’t there.

Section 3 on setting TESLA parameters seems to be the type of thing that one
would expect in this draft.  However, even in this section, there is very
little reference and tie-in with the TESLA RFC, and thus it would be good to
tighten this section up and refer to the appropriate sections and
definitions used in TESLA in this section and use the protocols that have
been standardized in TESLA.   A related comment is that it should be said
somewhere in this draft incorporates the TESLA RFC and inherits all of the
terminology of the TESLA RFC.

The bulk of Section 3 defines the format of bootstrap information signature
fields and authentication tags, and many related parameters.  It seems like
this format and information should all be defined in the TESLA RFC, or if
not in a related RFC within MSEC.  If this is all new to this draft and not
described in the TESLA RFC then this seems like a lot of new
formatting/information to be adding beyond TESLA, and I would feel a lot
more comfortable if this work were done in MSEC.

There are a number of other technical comments that could be made, but I
think the high level issue of how to split the work between MSEC and RMT
should be solved before addressing lower level technical issues.

Regards,
Michael Luby


_______________________________________________
Rmt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rmt