Document: draft-ietf-msec-srtp-tesla-04.txt Reviewer: Elwyn Davies [elwynd@dial.pipex.com] Review Date: Friday 9/23/2005 9:14 AM CST Telechat Date: IESG telechat, 29 September 2005 Summary: Not Ready; issues and nits. Summary Review: --------------- I reviewed this document for IETF Last call at Version 03. The major technical problem has been resolved (SRTP/TESLA is now specified correctly as a alternative authentication algorithm), and I think the related IANA considerations point has been corrected. I see that the document has not been made fully consistent around these changes - Section 6.1 ought to have been removed. Also the new version of the document has not addressed any of the other points which I made (which appears to be a different outcome compared with various responses I had from the authors after the previous review). This document is therefore not ready for Proposed Standard. There are clarifications and document updates that need to be made to achieve a version which could unambiguously generate interoperable implementations. 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: Length of the key chain: 'A telegraph pole uncertainty?' [Note on TESLA intro, RFC4082: S3.2 says that there is one-way chain oflength 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? [The reponse I had from the authors was that this didn't matter because the key chain was so long that it was essentially irrelevant. This surprised me because there are discussions about how long a particular key should be in use and I would have thought that it was an issue at the point where rekeying would be needed.] -------- 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. ============ 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: Some of the TESLA fields are specified as OPTIONAL in figures 2 and 3 and an OPTIONAL authentication algorithm in s4.1.. I am not sure that this is actually the best form of words now (or previously). TESLA is actually an alternative authentication algorithm and it would be good to state this in the last para of s2. In section 4.1 I think the OPTIONAL means optional to implement... once you start providing SRTP/TESLA the whole thing specified in this draft is mandatory - there is nothing optional within this draft that I can see. 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. I think these words are a hangover from when TESLA was couched as an OPTIONAL extra for the default authentication transform and in the revised nature of SRTP/TESLA as an alternative authentication algorithm I don't believe they are optional at all. Suggest omitting these sentences. ------------ HMAC-SHA1 is default, not the 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, next to last para: s/loss-tolerant/Loss-tolerant/ 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.1: This section is no longer needed and should be deleted. 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.