Last Call Review of draft-ietf-dhc-secure-dhcpv6-07
review-ietf-dhc-secure-dhcpv6-07-genart-lc-dupont-2013-02-24-00

Request Review of draft-ietf-dhc-secure-dhcpv6
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-02-25
Requested 2013-02-14
Draft last updated 2013-02-24
Completed reviews Genart Last Call review of -07 by Francis Dupont
Secdir Early review of -?? by Stephen Kent
Secdir Last Call review of -07 by Stephen Kent
Assignment Reviewer Francis Dupont
State Completed
Review review-ietf-dhc-secure-dhcpv6-07-genart-lc-dupont-2013-02-24
Reviewed rev. 07
Review result Not Ready
Review completed: 2013-02-24

Review
review-ietf-dhc-secure-dhcpv6-07-genart-lc-dupont-2013-02-24

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