Re: [dhcwg] comments on draft-ietf-dhc-sedhcpv6-10.txt

[Lishan Li <[e-mail]>]

Dear Jinmei,

According to your previous comment, I try to add the encryption algorithm
negotiation.

In order to support the encryption algorithm negotiation, the Encryption
option is defined. The Encryption option contains the EA-id(encryption
algorithm identifier) field. So the messages exchange is:
1. Information-request from client to server （ORO option contains code of
Certificate option）
2. Reply to the Information-request from server to client (Certificate
option, Encryption option, Server Identifier option are contained)
3. Encryption-Query from client to server (Solicit message contains the
Encryption option)
4. Encryption-Response from server to client

What do you think of the encryption algorithm negotiation method?

If the Encryption option is contained, the Reply(#2) message contains the
Certificate option and Encryption option. Then whether it is necessary to
contain the signature option for the message integrity check?

Looking forward to your further guidance.


Best Regards,
Lishan

2016-02-27 1:40 GMT+08:00 神明達哉 <[e-mail]>:

> At Fri, 26 Feb 2016 15:30:05 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > > > > [LS]: The self-signed certificate is the argument of the remove of
> the
> > > > public
> > > > key option. And we also need to supply some text to illustrate that
> it
> > > can
> > > > outweigh its cons. For the drawback of the method, the size of the
> DHCPv6
> > > > message is increased when we actually only need the public key, not
> the
> > > > certificate. However, the size of the X.509 certificate is not very
> > > large,
> > > > such as 1KB, which will not cause IPv6 fragment and other problem.
> > >
> > > Repeating my previous point just to make it sure that we are on the
> > > same page: the argument that a self-signed certificate should make a
> > > public key option redundant isn't new in our recent changes.  So I'd
> > > wonder why we are now bothering it.  If this is a completely new
> > > attempt of cleanup, I suggest making it very clear (i.e., it has
> > > nothing to do with mandated encryption etc) and discussing it
> > > accordingly.
> > >
> > > [LS]: The self-signed certificate make the DHCPv6 option redundant,
> which
> > is not a new problem caused by our defined mechanism. So we don't need to
> > bother it. Could you please check whether my understanding is correct?
>
> I didn't mean we "don't need to bother".  My major point is that this
> change was confusing:
>
> - We did a very substantial change since 08: merging encryption and
>   mandating it (as well as removing TOFU)
> - public key option was also removed as well without any explanation
>   of why
> - so I asked why, and your first response (it's because of the removal
>   of TOFU) didn't make sense to me: the argument with self-signed
>   certificate can apply with or without TOFU.
>
> That's why we have this conversation.
>
> Now, on clarifying these, I don't yet have a particular opinion on
> whether to remove the public key option.  But my suggestion is: if you
> want to make this change, raise this issue separately on this list
> with your rationale, get consensus, and apply it to a subsequent
> version of the draft.
>
> --
> JINMEI, Tatuya
>