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

[Lishan Li <[e-mail]>]

2016-02-26 1:53 GMT+08:00 神明達哉 <[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").
>
> [LS]: Agree. For the Reply message (#2), it does not contain the timestamp
option
because of the cleartext transmission. For the subsequent encrypted
message, the
timestamp option is used for message integrity check.
In general, in order to defend against the anti-replay attack, the
timestamp option
is used. As you said, the trivial sequence number can make it more simpler.
But if
the trivial sequence number is use, we need to define the format of the
trivial
sequence number. If the timestamp option is used, we can use the format
defined in
Section 5.3.1 of RFC3971.

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

Best Regards,
Lishan