I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-secure-dhcpv6-07.txt Reviewer: Francis Dupont Review Date: 20130220 IETF LC End Date: 20130225 IESG Telechat date: 20130228 Summary: Not Ready Major issues: the proposal fails to provide the expected security, in particular it does nothing real against replay and the basic function (anti-spoofing) relies on pre-configuration. Minor issues: some but major issues should imply enough changes to make them more candicates for comments Nits/editorial comments: (including technical comments) - first the I-D format is not followed (printed the 17 pages with 4 pages per sheet gives 9 sheets...) - Abstract page 2: IMHO the Abstract should be first (i.e., just after the title and before the Status of this Memo) - I know well SeND so when I compare to it I can see a lot of issues. To summarize SeND uses 4 devices: nonces, timestamps, CGAs and a PKI. Nonces and timestamps are for anti-replay (IMHO nonces have a crypto function too as they introduce unpredictable random in messages, but I don't know if it is an important point or not). CGAs are for authentication and message integrity. The PKI (known today as the RPKI) is for authorization, i.e., the prefix is checked to be really assigned to the entity running the router. When I compare to the secure DHCPv6 proposal I can get only the CGA part. There are timestamps but one way and without any text explaining how to apply them (i.e., the proposal is incomplete about this point: anti-replay). The authorization problem is not addressed until the end of the document where pre-configuration is introduced. BTW the current DHCPv6 security is mainly rejected because it requires pre-configuration (of course it has many other problems but this operational one is as far as I know the most blocking one). - 1 page 3: I'd like to see anti-replay and authorization issues at least mentioned here. - 3 a page 3: ownership doesn't protect against fake, it protects against impersonation, i.e., with CGAs a fake server can launch an attack but nobody can impersonate the legimate server. So either the description of the attack is wrong or the protection mechanism is not the right one. - 3 b page 4: i.e. -> i.e., - 3 c page 4 (comment): in fact the reason IPsec is rarely used to protect relay/server communication is not because IPsec is hard but because usually this communication is inside the ISP internal infrastructure so is not subject to easy attacks. With other words the vulnerable part is the client/agent communication over a very unprotected LAN, a wireless LAN for instance, where of course IPsec is not applicable. - 4 page 4: abovementioned -> above mentioned or above-mentioned? - 4 page 5: replay protection is mentioned, there is a timestamp field in the signature option but nothing about how to use it... - 4.2 page 5: IMHO the text about collision could be removed: it is well known collisions are not a problem in this case. And algo agility is something one wants a priori, so it doesn't need a bad argument to support it. BTW if you can't find a general IETF document explaining why algo agility is good we can ask the security directorate to make a formal statement. In anycase you should get something to reference... - 5.2 page 8: in the signature please put the tag value in its own line (so implementors can more easily cut and paste it). - 5.2 page 9: I am not sure the wording of the padding is very correct... - 5.4 page 10: section 5.1 and 5.2 -> sections - 6.2 page 12: where is the text about timestamps? With the current processing rules a relay attack is trivial (so either you remove anti-replay from the threats the proposal deals with, or you complete the proposal). - 6.2 page 12: someone suggested for DNSSEC to avoid silly large RSA exponents too. (comment (as you wrote prudent practice...)) - 7 pages 14 and 15: I have nothing against this security considerations but unfortunately as they are well written they kill most of the interests in the proposal: - anti-spoofing provided by pre-configuration (i.e., you can also pre-configured shared secrets for authentication/integrity) - no downgrade protection when compatibility is kept. - another text about collisions (please keep this one and remove the section 4.2 one) - 9 page 17: IMHO Dorms -> Droms ... Regards Francis.Dupont at fdupont.fr