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