Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

[Tomek Mrugalski <[e-mail]>]

On 26/10/14 12:11, Bernie Volz (volz) wrote:
> This message starts the (short) DHC working group last call to advance
> "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-04, document as a Standards
> Track (Proposed Standard) RFC. The authors believe that this version is
> ready. We had a WGLC earlier (May 2014 for the -02 version) and there
> were some comments, so this is primarily to assure that those comments
> were addressed.
>
> Tomek is the assigned shepherd for this document.
Apologies for taking it so long to get this review done.

This is my shepherd's review of this draft.

I did review -04 version of this draft and I support this work moving
forward. I have quite a few comments, but they are easy to fix and
rather editorial in nature.

I rechecked my previous review comments (sent on May 30). Thank you for
addressing them. The only unaddressed comment is about key and cert
rollover. There's nothing to change in how the mechanism is working, but
perhaps you could add a section about rollovers. For clients moving to a
new certificate, it should be pretty easy - once the old one is about to
expire, the client gets a new cert and starts using it. The server will
verify the new signature and it will all work. Updating the server keys
will be trickier. From the client's perspective, probably another leap
of faith would be required. In fact, a server updating its keys would be
indistinguishable from a new rogue server pretending to be the
legitimate one. Anyway, this is something that should be discussed, but
I don't think there's anything you need to do here protocol wise.

The text in section 3 could be improved. It mentions that there are two
key management mechanisms. The first is mentioned immediately
("Firstly,..."), but the second one is mentioned 3 paragraphs further
down. How about this:

  For the hash key function, there are two key management
  mechanisms.  The first one is a key management done out of band,
  usually through some manual process. The second approach is to use
  Public Key Infrastructure (PKI).

  As an example of the first approach, operators can set up a key
  database for both servers and clients which the client obtains a key
  before running DHCPv6. Manual key distribution runs counter to the
  goal of minimizing the configuration data needed at each host.

The next paragraph mentions this: "[RFC3315] provides an additional
mechanism for preventing off-network timing attacks using the
Reconfigure message: the Reconfigure Key authentication method.
However, this method provides no message integrity or source integrity
check.". I disagree. It provides both, but the protection is very weak.

Section 4, first line on page 5. CA is mentioned for the first time, but
the name is explained. Please replace its first use with "Certificate
Authority (CA)".

Section 5.1: Please rename OPTION_PK_PARAMETER to OPTION_PUBLIC_KEY. It
will be more intuitive.

Section 5.2: Please rename OPTION_CERT_PARAMETER to OPTION_CERT.

Section 5.3:
"both signature and authentication option are presented" =>
"both signature and authentication option are present".

Section 5.5 should include a brief introductory text. Maybe the
following would be useful: "The following new status codes are defined.
See Section 5.4 of RFC3315 for details.".

Section 6.1 "The client MAY switch to other certificate if it has." =>
"The client MAY switch to other certificate if it has another one."

The following two sentences contradict each other "But it SHOULD NOT
retry with the same certificate.  It MAY retry with the same certificate
following normal retransmission routines defined in [RFC3315].". Better
way to express the intention would be: "If client decides to retransmit
using the same certificate after receiving AuthenticationFail, it MUST
NOT retransmit immediately and MUST follow normal retransmission
routines defined in RFC3315."

Section 6.2
"multiple Signature option is presented" =>
"multiple Signature options are present".

"If neither of the Signature, Public Key or Certificate options is
presented,". I'm not 100% sure on this one, so I ask a native speaker to
confirm it, but I think that neither means "not one or the other" and
can be used only if there are exactly two alternatives. So it would be
better to say:

"If none of the Signature, Public Key or Certificate options is
present,"

"A fast search index may be created for this list." This is an
implementation detail and I'm not sure if it should be placed in the
draft. But I won't insist if you want to keep it.

"It restores public keys from all trustworthy senders." =>
"It stores public keys from all trustworthy senders."

The text starting with "Furthermore, the node that supports the
verification of the Secure DHCPv6 messages MAY record the following
information:" mentions minbits explicitly, but maxbits implicitly. I
think it would be easier to say something like "The node MAY impose
additional constraints for the verification. For example, it may
impose limits on minimum and maximum key lengths."

Section 6.4:
"After the signature verification also successes" =>
"After the signature verification also succeeds"

Section 6.4 does not mention that the timestamps must be strictly
monotonously increasing. Right now, an attacker can capture a valid
packet and then replay it rapidly as long as the inequality holds.

Section 7. Your refer to the same feature as leap-of-faith, Leap of
Faith and mention its abbreviated form (LoF) multiple times, yet almost
never use LoF on its own. Please make this consistent throughout the
document. Oh, and section 7.1 mentions "Leaf of Faith".

"such as a network cafe" =>
"such as a network in a cafeteria".

Section 8 - I think it would be a good place for a discussion about
key/certs rollovers. See my comments at the beginning of this mail.

Sedhcpv6 deployment has privacy implications. You should discuss them,
even if very briefly. I'm not sure what's the best way to express it.
Maybe saying something that secure clients should not expect any privacy
as they reveal additional information in their certs? That's not a bad
thing, it's just client privacy and client authentication are in
practice mutually exclusive.

Section 9
"This document defines three new ..." =>
"This document defines four new ..." (also three => four) further down
the same paragraph.

Section 10
"IETF DHC working groups". There's only one DHC WG :)

Please replace reference to 5996 with 7296.

Ok, that's it. Even though the number of corrections is significant,
they are all editorial in nature. I strongly support this document
moving forward. Thank you for doing this work. I find it highly useful.

Tomek