Subject: [dhcwg] proposal: make draft-ietf-dhc-sedhcpv6 more client-side centric

From: 神明達哉 <[email-masked]>
Date: Thu, 19 Feb 2015 10:20:36 -0800

As a followup to my previous message, this is my personal proposal for
the "use case" issue of draft-ietf-dhc-sedhcpv6.  This is mostly
self-contained, but it's probably better to read the previous message
first.

As I stated in the previous message, I think the main issue in this
sense is about authenticating clients at a server.  In my
understanding, it's much less controversial for the case of
authenticating servers.

So my basic point of the proposal is to make this document more focus
on authenticating servers, and describe in more detail what's the
problem and how the proposed mechanism solves it.  We generally leave
authenticating clients beyond the scope of this document, and don't
describe details specific to that case.

More specifically,

- Revise Section 1 (Introduction) and 3 (Overview) so they will more
  focus on authenticating servers.  Give a more detailed problem
  statement in either Section 1 or 3, with the explanation of how
  sedhcpv6 solves it.  Possible use cases (if they are still
  considered useful and less controversial) would probably belong
  here, too.
- In Section 1, declare the case of authenticating clients is beyond
  the scope of this document, even if clients can send some of the
  security options to the server and the document would describe how
  servers would handle it to the extent they are necessary for the
  main topic.
- Revise Section 6 (rules and behaviors) so it concentrates on the
  main use case.  In particular, since client authentication is not
  in the scope, the server would basically only use the received
  security options as a signal for using the mechanism and to know the
  algorithm the client wants to use.  Further details would probably
  be beyond the scope of the doc.
- Remove Section 7
- Adjust Section 8 to match the sense of the focus (e.g., remove any
  note specific to the case of authenticating clients).

This is closer to option #3 I showed in a previous message:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg16211.html

But this revised proposal does not explicitly limit the use cases,
just saying some points are out of scope if we are not certain about
how/why for them.  This way we can avoid sending the wrong signal that
this mechanism solves issues for cases where we don't know if it
really does, and avoid wasting people's time to implement something
possibly useless or even harmful just because it's published in an
RFC.  Yet many of the protocol components will still remain, so a
well-educated die harder might try to implement and use it for the
open case and may really find it useful.  If that's the case, that
would be great, and we can then describe the rest of the details with
actual experiments.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Feb 2015 14:02:32 -0500

On Feb 19, 2015, at 1:20 PM, 神明達哉 <[email-masked]> wrote:
> Revise Section 1 (Introduction) and 3 (Overview) so they will more
>  focus on authenticating servers.

I am hugely uncomfortable with this proposal.

The whole problem with the document as I see it is that it treats clients and servers as having distinct security models, when we do not actually know what security model will be used.   I don't mean to say that clients and servers won't have distinct security models, but we don't know what those security models will be.

This appears to me to be a classic example of the "mechanism, not policy" philosophy that the Athena project used to follow.   We are providing a mechanism here.   How it will used appears to me to be out of scope at present.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 19 Feb 2015 14:15:58 -0800

At Thu, 19 Feb 2015 14:02:32 -0500,

> I am hugely uncomfortable with this proposal.
[...]
> This appears to me to be a classic example of the "mechanism, not policy" philosophy that the Athena project used to follow.   We are providing a mechanism here.   How it will used appears to me to…

Hmm, so it looks like we have to agree to disagree on this fundamental
point:-)

>> If the protocol can be completely independent from these issues, it
>> might make sense to publish the protocol part first.  But I suspect
>> that if and when we figure out these points the result will affect
>> protocol details.  Or we might even find that this kind of security
>> mechanism is not a viable solution to the stated problem in the end.
>> That's why I requested we first clarify exactly what kind of problem
>> this mechanism can solve and how it does so.  The section that
>> explains possible use cases is an attempt to address that concern.
>> But, according to the review feedback and the followup thread, that
>> attempt seemed to fail, at least for the case of authenticating
>> clients.

>> So my question to the wg would be: "whether it's okay to publish a
>> mechanism with details of the case of authenticating clients without
>> knowing specially how it's used or whether it really solves 'key
>> distribution problems'".  If the answer is "Yes", our next step would
>> be remove the use case section and move it forward.

I'll see what's the latest consensus of the wg on this question at the
moment.

--
JINMEI, Tatuya