Re: [dhcwg] Open Issues for Secure DHCPv6

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

At Wed, 15 Jun 2016 22:57:11 +0800,
Lishan Li <[e-mail]> wrote:

> After the discussion with authors and Stephen Farrell, we have the
> following problems not sure and want to get further comments from WG.
>
> 1. For the applicability part, after the discussion with Jinmei, we want to
> made the following changes:
> (1). Add some opportunistic security related description in applicability
> part;
> (2). Support the following two modes of operations: 1.
> Authentication+Encryption with cert/public key validation; 2. (if #1 isn't
> possible) Encryption-only without cert/public key validation.
>    The current version only includes "Authentication+Encryption" mode. We
> should add the "Encryption-only" mode.

I think some more background explanation is needed here...this is
simply based on my *understanding* (not opinion) of what we agreed at
the Yokohama IETF meeting.  I thought our consensus was to support the
above two modes, while the current sedhcpv6 draft only talks about
Authentication+Encryption.  I guess there is some possible confusion
on what "TOFU is out of scope for now" means
(see agenda #4 of https://www.ietf.org/proceedings/94/minutes/minutes-94-dhc).

My understanding is that it was only about authentication and the
consensus was to add support for "encryption only".  Am I
understanding it correctly?

BTW, if we make this change, I don't think we can simply update the
applicability section - it will lead to quite substantial overhaul for
the entire document.

> 3. The Reply message with an error status code, is not encrypted. So the
> Reply message may contain the client identifier option, then the client's
> privacy information may be disclosed.
> So the solution is that: The Reply message can be encrypted to avoid
> privacy information disclosure.

This is not so trivial.  At least it will be tricky in case of
'AlgorithmNotSupported' - how can the server encrypt it when it
doesn't support the encryption algorithm?

--
JINMEI, Tatuya