Subject: Re: [dhcwg] Open Issues for Secure DHCPv6

From: Lishan Li <[email-masked]>
Date: Sat, 2 Jul 2016 17:58:16 +0800

Dear Jinmei,

Please see inline.

Best Regards,
Lishan

2016-06-16 1:04 GMT+08:00 神明達哉 <[email-masked]>:

> At Wed, 15 Jun 2016 22:57:11 +0800,
> Lishan Li <[email-masked]> 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.
>
> [LS]: Sure. Besides applicability section, we should update the whole
document
to describe the encryption-only mode. In addition, we also need to some
explanation
on why Tofu is out of scope currently. Right?

> > 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?

[LS]: If the server does not support the algorithm that the client used.
It can encrypt the Reply message with the mandatory algorithm.
Right?