[dhcwg] missing pieces for the Secure DHCPv6 draft

[神明達哉 <[e-mail]>]

I'm resuming an old thread with renaming the subject as it seems to
require discussions on broader topics.  I'll begin with this message
from Francis: https://mailarchive.ietf.org/arch/msg/dhcwg/82ZGOz7DGBZf4hSvcIaTC8-iK4w

On Tue, Oct 6, 2015 at 12:45 PM, Francis Dupont
<[e-mail]> wrote:

> BTW I can see 2 "sure" senarios for deployment:
>  - secure DHCPv6 as a complement of SEND. In this case all the PKI
>   issues are already solved at the SEND level at the protocol level
>   (i.e., a router (e.g., the router which puts the M/O bit(s) in RAs
>   asking for DHCPv6) already provided the certificate validation stuff
>   (e.g., certificate chain, crls, etc)) and at the organization level
>   (e.g., X.509 prefile).
>
>  - static pre-configuration of credentials. In this case the environment
>   is closed and everything was installed offline before secure DHCPv6 use.
>   At the limit, it is enough to verify the "right" certificate (or raw key)
>   is used. Using the draft terminology, clients are configured with the
>   server certificate/key and the server has a table matching each client
>   with the corresponding certificate/key (BTW it is a common way to perform
>   authorization from a PKI): this is the "local trust certificate list".

Based on some off-list discussions, I've realized that we were
required to provide more background discussions than deployment
scenarios.  In my understanding we'll need to cover the following
points:

1. threat analysis on DHCPv6 security (especially in the context of sedhcpv6)
2. specifically how the two models of sedhcpv6 can be used to address
   these threats
3. some consideration on DHCP-specific difficulty such as the chicken
   and egg problem of how to get/validate the server certificate
   before starting a DHCPv6 session

For point #1 I found an expired draft for DHCPv4 authentication seems
to be a pretty good reference already:
https://tools.ietf.org/html/draft-ietf-dhc-v4-threat-analysis-03
We can probably just borrow some key parts from this document.

For point #2 and #3, I think we'll need to use lessons learned so
far.  Specifically:

- We should be honest: we cannot simply and casually say "this is out
  of scope" for difficult related issues (these are generally related
  to key distribution problems).  If something is really difficult and
  still open, we should clearly state that, and, if necessary, may
  have to consider remove some features from the current spec.
- We need to be realistic: we know speculative deployment scenarios
  won't satisfy a sufficient number of people.  As we don't have a
  good precedent on deployments, this will be difficult.  But we'll
  need to try to find a few very simple scenarios that most of us can
  hopefully agree on, and we should honestly say we don't yet know
  scenarios for areas where we can't find such a simple case.  (And,
  if necessary, we may have to remove some features).
- We shouldn't oversell the spec: this is a corollary of the above
  two.  Like in the case of applicability of TOFU, if we cannot find a
  realistic explanation of how we can use some of the described
  feature, we should rather drop it than try to make an unconvincing
  argument to insist it's necessary.  If, as a result of this, the
  spec becomes too small to matter, although I hope this won't be the
  case, then it would mean it's really premature to discuss this
  mechanism.  In that case we should conclude we drop it this time.

According to these observations, I suspect the "compliment of SEND"
scenario looks too unrealistic, given SEND itself hasn't been deployed
at all.  It may be an interesting research topic, but I suspect it
won't help advance the sedhcpv6 document.

Regarding the second, I think we'll need to explain either:
- how specifically this will decrease deployment costs compared with
  statically pre-configuring shared secrets in more detail, or
- this won't be that different in terms of deployment costs, but would
  be considered a bit more securer in that client secret won't have to
  be stored in the server

--
JINMEI, Tatuya