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

[Lishan Li <[e-mail]>]

2016-02-25 1:56 GMT+08:00 神明達哉 <[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.
>
> [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.

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


> > > > > >- 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]: Will participate in the discussion.


> > > [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.
>
> [LS]: Thanks a lot for your guidance. I think that Bernie's reply has
solved this problem.


Best Regards,
Lishan