Hi, Francis, Thanks so much for your detailed review. Your comments are important for us to improve the draft. We will work on that in the next update. Maybe some private communication will be for your further advices.
Many thanks and best regards, Sheng >-----Original Message----- >From: [email protected] [mailto:[email protected]] >Sent: Monday, February 25, 2013 1:38 AM >To: [email protected] >Cc: [email protected] >Subject: review of draft-ietf-dhc-secure-dhcpv6-07.txt > >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 > >[email protected] _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
