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

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

(I've removed [e-mail])

At Tue, 23 Feb 2016 10:45:40 +0800,
Lishan Li <[e-mail]> wrote:

> > I'm still not sure if my point was made clear...so let me be more
> > specific: in the following message exchanges:
> >
> > 1. Information-request from client to server(s)
> > 2. Reply to the Information-request from server(s) to client
> > 3. Encryption-Query from client to server
> > 4. Encryption-Response from server to client
> >
> > did you mean the Reply message of exchange #2?
> >
> > If so, do you at least agree that it makes almost no sense to include
> > the explicit separate signature in messages 3 and 4?
> >
> > [LS]: Yes, I mean the Reply message of exchange #2. The reply message
> contains the signature option and timestamp option for message integrity
> check. In the #3 and #4 messages, the DHCPv6 messages are encrypted, so the
> signature and timestamp option are not contained.
> What do you think of it?

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.

> > Right, but this argument also holds even if we have TOFU...
> >
> > > So, I think that
> > > the certificate option is enough for authentication.
> > > Looking forward to your further guidance.
> >
> > ...so these don't explain why we should now remove the public key
> > option.  One obvious, though possibly relatively minor, drawback of
> > only having a certificate is that it will make the message size even
> > bigger when we actually only need the public key.
> >
> > I'm not necessarily opposed to removing the public key option if we
> > cover all such discussions and reach consensus, but I don't think I've
> > seen it yet.
> >
> > [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.

> > > > >- Section 6

> > Introducing a new error code is related but a minor point.  My
> > question was about what the client should do if it sees that code (or
> > whatever signal that indicates this kind of failure).
> >
> [LS]: As you said before, the DecryptionFail failure is equivalent to
> SignatureFail. So if the client sees that code, the client MAY resend the
> message following normal retransmission routines defined in [RFC3315].
> Am I correct?

Not sure if you are correct:-), but, yes, that answers my question.
Whether this behavior makes most sense is a different question, on
which I don't yet have a particular idea.  Maybe I should first see a
revised draft in full text.

> > p.s. there's another bigger open issue I separated from the rest of
> > the discussions:
> > https://mailarchive.ietf.org/arch/msg/dhcwg/-tZBpeMs-EiVyMm0MLBpj3dFYNI

Reminder: this is still open.

> > [LS]: Another open isssue is that:
> If the server receives the Information-request message but it does not
> support this work, what should the server do?
> In my opinion, if the server don't support this work, it has two choices:
> 1. drop the received Information-request message;
> In this way, the client will not receive any message which illustrate the
> server don't support secure DHCPv6. If there is no authenticated DHCPv6
> server, the client may resend the Information-request message;
> 2. send the Reply message with the corresponding error status code to the
> client；
> This way will introduce the downgrade attack, a third party may send the
> Reply message with the corresponding error status code. And then the DHCPv6
> configuration process may be unsecured.
> I prefer the first one solution. Which one would you prefer? Looking
> forward to your guidance.

I'd simply expect the usual behavior: the server will return a Reply
(obviously) without the requested information (which, in this case,
the certificate or public key option).  I don't think we can eliminate
the possibility of downgrade attack by an on-path attacker, however we
specify the behavior in this case.

--
jinmei