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

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

At Thu, 25 Feb 2016 20:45:16 +0800,
Lishan Li <[e-mail]> wrote:

> > Okay.  So focusing on the Reply message (#2): my point was:
> >
> > - in effect, its only content is the certificate (or public key).
> > - the recipient is already expected to validate this only content
> >   directly (by comparing it with locally pre-configured info, by using
> >   a PKI, etc), so we do not necessarily need to provide additional
> >   integrity protection for it by signing the message.
> > - on the other hand, if we eliminate the signing and the signature
> >   option from this, we'll completely eliminate this option from the
> >   protocol.  This will help make the protocol simpler and reduce
> >   development costs.
> >
> > If you still disagree, perhaps it helps if you can show a specific
> > attack vector because of the lack of the signature.
> >
> > [LS]: Agree. But if we don't need the signature option, then the timestamp
> option makes no sense, which is used to defend against anti-replay
> attack before.

For #2, correct.  We'll still need the timestamp option, though, for
the anti-reply protection of encrypted messages. (We might be able to
make it simpler such as a trivial sequence number, exploiting the fact
that the message is encrypted.  In that sense, it may not have to be a
"time stamp").

> > > Right, but this argument also holds even if we have TOFU...
[...]
> > > > [LS]: In consideration of the support of TOFU and the add of all such
> > > discussions and consensus, the better way for us is to add the public key
> > > option as the before secure DHCPv6 version.
> > > Am I correct?
> >
> > No, I just didn't see why the public key option was removed (the
> > explanation regarding TOFU didn't make sense to me).  As I already
> > said, I'm not necessarily opposed to removing it if there's a
> > convincing reason that can outweigh its cons.
> >
> > [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.

--
JINMEI, Tatuya