Last Call Review of draft-ietf-msec-tesla-for-alc-norm-
review-ietf-msec-tesla-for-alc-norm-secdir-lc-sheffer-2009-08-03-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document applies the TESLA multicast authentication protocol to ALC and
NORM, two reliable multicast protocols. It is very much a security document,
and must have been reviewed by numerous security experts - and it shows.

General

Overall this is a good document, but I suspect that it has too many options
and leaves too many things open as to be truly interoperable. So
Experimental is the right designation. From a security point of view, things
seem to be well covered, but see my two comments below.

Security Issues

4.2.2.2: it is far from clear that if I trust you to send me packets (a
movie, say), I also trust you to configure my NTP client (list of servers
and trust anchors for them). So I wonder if using one of the offered NTP
servers should really be MUST. Or are we really expecting a separate
application level NTP layer, on top of that maintained by the OS?

6. The Security Considerations have no discussion at all of the security of
the back channel. I understand that such a channel does exist, at least for
NORM. This channel remains unprotected (or its protection remains
unspecified, see Sec. 1.1). Can it be used to DOS the sender? Other
receivers? Are additional attacks possible?

Other Comments

2.2: leaving the bootstrapping step implementation-dependent means that the
protocol is non-interoperable.

3.1.2.2: this section implies (last paragraph) that the use of periodic
bootstrap information is only applicable for the case where direct time
synchronization is used. Is this required by the TESLA protocol?

3.4.3: the description of the “Disclosed Key” field says it must be 0 in the
first d intervals, which contradicts the last paragraph of the section,
where it is forbidden to use this tag in those intervals.

3.4.7 (and elsewhere): I wonder about the design choice of making the length
of the NSB (and hence, the explicit part of the interval index) depend on
the size of the truncated MAC. The considerations for selecting one are
primarily security-related, while for the other they are primarily about
bandwidth and reliability. Why make them dependent?

4.1: the text “verify the Group MAC if present” is misleading (an attacker
might remove it from the packet). It should be “if the G bit is set in the
Bootstrap message”.

4.3, step 5: when doing congestion control, isn’t there value in keeping
key-disclosure packets, even when other packets are dropped? The effect of
key-disclosure packets being dropped may be dozens of other packets that are
lost.

4.3: I find this text self-contradictory: “In this specification, a receiver
using TESLA MUST immediately drop unsafe packets.  But the receiver MAY also
decide, at any time, to continue an ALC or NORM session in unsafe mode,
ignoring TESLA extensions.” I would have felt somewhat better about it if
the text said something like “there SHOULD be explicit user action to move
to unsafe (insecure) mode”.


Attachment:


smime.p7s




Description:

 S/MIME cryptographic signature