Draft: draft-ietf-msec-srtp-tesla-03.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Thursday 7/14/2005 5:50 AM LC Date: 11 July 2005 Summary: In my opinion this document is not ready to go to the IESG. It has (in my view)significant issues. The major one is whether (for technical reasons) it can be treated as an optional add-on to the SRTP RTP profile, and even if it can, whether it would be better treated as a separate profile, facilitating application negotiation of specific capabilities - i.e., stream encryption/authentication (use SRTP), rigorous source authentication (add TESLA). I am not an expert in this area so it is quite possible that I am wrong about the technical point but I think making it a separate profile would have merit irrespective of the technical issue. In the process of reviewing this, I identified a potential problem in RFC4082 - a telegraph pole problem with the length of the key chain - which has some knock-on effects into this specification. Detailed Review: Substantive points: Is this a separate RTP profile? I have some difficulty understanding how the proposal can be an optional extension of SRTP: This is proposed in s4.3 to be implemented by adding a new flag to the Transform Independent parameters of the SRTP cryptographic context. The intention appears to be that the proposal reverts to RFC3711 SRTP if this bit is not set. Inspection of s3.2.1 of RFC3711 does not reveal a generic flag bit word in which this flag could be placed, so I am at a loss to determine how the proposed enhanced profile can be interoperable with existing implementations of SRTP that do not understand TESLA. It seems to me (from my very naive perspective on RTP and SDP etc) that SRTP/TESLA has to be a separate RTP profile. Defining this as a new profile would appear to conform to the general usage of this sort of scheme - an application can negotiate for RTP/STP/TESLA if it feels the need, falling back to RTP/SRTP or plain old RTP if the user will accept the reduced security. From another point of view, it is a whole other capability on top of the stream security which SRTP provides and conflating it with the SRTP profile doesn't seem to make sense. This of course would have knock on effects on the IANA considerations. --------- Length of the key chain: 'A telegraph pole uncertainty?' [Note on TESLA intro, RFC4082: S3.2 says that there is one-way chain of length N made up of K_0, K_1, -> K_N... This appears to have N+1 keys but, of course, N links. Is the list of keys wrong or does the length give the number of links?] This uncertainty links to item 10 of s4.3 - just how many keys are there in a key chain of length n_c? Is this number the number of links or the number of keys? -------- SRTCP average packet size: Probably in s4.5 or 4.6, there needs to be a note indicating whether (I think they need to be ) or not the extra fields need to be incorporated in the 'avg_rtcp_size' (s3.4 of RFC3711, s6.3.3 of RFC3550). (There is text related to the packet size increase in s6). ---------- Session Cleanup: s5: Firstly, I think the sentence 'This repetition might abruptly stop, however, if the key-bearing packets stop abruptly at the end of the stream.' is garbled. Maybe it should be 'The reliability will be compromised if the flow of packets terminates abruptly when there is no more data to send, so that the keys for the last few previous packets are never sent.' In the next sentence the implementer is instructed to 'send null packets with TESLA keys for one entire interval'.. how many and how frequently? Presumably this will depend on the length of the interval and some view of the reliability but I think guidance is required. ------------ IANA Considerations: s8 claims this document has no registration requirements. This does not appear to be true. If, as I suggest above , this is really a separate RTP profile, the document defines an RTP profile which needs to be named and registered [RFC3711]. Whether or not this needs to be done, the specification needs to define one or more registries for the One Way Function identifiers (CTANs in the terminology of draft-ietf-msec-tesla-spec-00.txt), and maybe the overall cryptographic context. ============ Semi-substantive: Key and MAC lengths: s4.1/s4.2/s4.5: The lengths of the Disclosed Key and TESLA MAC fields are determined by the one way functions used to setup the key chain and generate the MAC. This is discussed in 4.3: It would save head scratching to mention this earlier since the packet format doesn't have explicit lengths. s4.2: Just for clarification, the Disclosed Key and TESLA MAC fields are specified as variable length. The figures show them as ending on 32 bit boundaries. Is this merely for convenience in drawing or is there any constraint on the length of the fields. Presumably it would be at least good for them to be multiples of 8 bits. s6.2: This section specifies various options for the OWF and the key and MAC lengths generated. It doesn't say they are in bits, and it would be worth linking the lengths to the 'Disclosed Key' and 'TESLA MAC' fields in s4.1/4.2. Also, mentioning that RFC2104 defines HMAC-SHA1 would be helpful. ---------- Dealing with Disclosed Keys in Sender and Receiver: s4.4.1: Item 6: A few words indicating that the disclosed key possibly needs to be updated from what was sent previously (and what drives this) would be useful. s4.4.2: para 6: Since this part is couched as a set of processing to be performed on a current packet, the start of the second sentence might be better as: 'Check if the current packet contains a new disclosed key from the current time, the time interval of the last disclosed key and the key disclosure interval: if the disclosed key is a new one, determine the index of the key. If any keys in the chain have not been received as a result of lost packets, calculate the intervening keys (give a ref to how). Using these newly obtained keys, perform TESLA verification on any buffered packets to which they apply using the rollover counter...' ---------- Optionality of TESLA: TESLA is specified as an optional profile.. I found the words in the 'Note' sentence of the captions of Figures 2 and 3 confusing... It could be read as TESLA fields being optional on a per packet basis. Everything about the 'optionality of TESLA' is said in the paragraph before each figure in a much clearer way. Suggest omitting these sentences. ------------ HMAC-SHA1 is default, not only possibility for MAC algorithm? s4.6: last para: This appears to imply that HMAC-SHA1 is the *only* possible algorithm for calculating the TESLA MAC. This seems to contradict s4.3, Item 5 where the MAC algorithm is specified as a parameter. This needs to be clarified/corrected. Editorial Nits: global: s/bytes/octets/ (3 instances) global: consistency of usage of f/f' vs F/F' for the OWFs Abstract: s/loss/Loss/ s1, para 3: s/discern/distinguish/ s1, last para: s/loss/Loss/ s1.1, para 2: s/familiar/is familiar/ s3, para 3: S/needed/necessary/ s4.1, para 1: s/The fields added by TESLA are called "TESLA authentication extensions" altogether/The fields added by TESLA, considered as a group, are called "TESLA authentication extensions/ s4.4.1, s4.4.2: s/included/inclusive/ s4.4.1: Item 9: It would not hurt to expand ROC (rollover counter). s4.4.2: s/is the following/is as follows/ s4.6: para 5 (1st bullet): s/as for/as described in/ s4.6: para 6 (2nd bullet): s/as for Section 4.2/as described in Section 4.5/ s6.2/s11: RFC2104 is referenced in s6.2 (and elsewhere) but the reference is missing. It might be useful to put this ref against the first usage of HMAC-SHA1 in this section (although it has been refeerenced before). s6.2: A reference back to the definitions of the crypto context variables in s4.3 would help. s6.2: OUTPUT LENGTH of TESLA KEYCHAIN OWF is n_p s11: References to RFC2119 and RFC2104 are missing.