Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

[Robert Elz <kre at munnari.OZ.AU>]

    Date:        Mon, 14 Jul 2008 10:59:39 -0400
    From:        "Bernie Volz (volz)" <volz at cisco.com>
    Message-ID:  <8E296595B6471A4689555D5D725EBB21080CA037 at xmb-rtp-20a.amer.cisco.com>

  | This seems like a catch-22. How can someone determine the length of the
  | Digital Signature field as there's no indication of how long the pad
  | field is.

The signature isn't just bits, it is an encoded field, its length is
determined by the first few bytes.   No-one bothers specifying this
because its all defined by the common (non IETF) standard that sets
how these things are represented.

  | Therefore, the Digital Signature field's length MUST be known based on
  | other information (key, etc).

I think it is possible to work out how long it will be (so for eaample,
space can be allocated to store the result of the calculation), but the
key is certainly required to do that.   Since ideally you want the private
key accessible for as little time as possible (so it doesn't end up in crash
dump images, etc) you re

  | So, sure, putting 0's in the 100s of bytes and, likely more
  | significantly, having to calculate the signature over those additional
  | bytes is a cost.

It's just the hash function, which isn't that expensive, what's more
annoying is having to actually do this, especially for validation.
(as it means saving the old value elsewhere before inserting the 0's).

The truly computationally expensive part of all of this is the RSA
encryption, but that's of the result of the hash, which is a short(ish)
fixed length bit string, and none of this is making any difference at
all to that.

  | If we feel that is a burden, using multiple fragments is the way to go.
  | Based on the original write-up in the draft, this is required anyway so
  | there's really no savings.

In your previous message you said (I am interposing this here as it
is relevant to this point ...)

  | The reason is that it is often easier to (temporarily) add data at the end of
  | the message than to have allocated sufficient space BEFORE it (and at least
  | KRE wants to avoid having to use multiple buffer fragments to hash over). 

which isn't it exactly, though it may have seemed like that from
what I said before.   It isn't calling the hash func multiple times
that causes problems - for the usage here, the calls are all fixed
length known position buffers (addresses, and that tag, whose purpose
someone who knows hash function theory much better than I is going to
need to explain to me one day...) so they're easy.   The part that causes
problems (or easily can) is the bit that deals with finding where the
bits of the packet are that need to be included, and making sure the
right bits are there - especially if it turns out that everyone actually
puts the sig last in practice, so the code for dealing with the part of
the packet that comes after the sig is never exercised.

Of course, if everyone copies your method, and sticks the sig in the middle
(or Ted's plan) then this won't be a real issue - I just couldn't imagine
anyone actually writing this code that way.

Back to the main message to which this is a reply for this next quote...

  | It does require one more fragment than the original specification (the
  | data beyond the end of the option). For the nodes that always add the
  | option as the last option (based on their choice to do so), they can
  | avoid this last fragment. But, of course they can't assume this when
  | receiving a message.

The server has no problem, it just always puts the option last (if it
wants, or is required to by the spec) and everything is easy.   But as
you say, the client has to deal with all legitimate possibilities.   That
means (unless the spec prohibits it) that extra fragment at some place in
the packet that must be correctly calculated (start & length) plus dealing
with the possibility that they may rarely, if ever, actually get to exercise
the code that handles this, if, as I believe likely, servers all just put
the option at the end.

To end my participation in this issue - this really all boils down to a
judgement call, is the demand for "option purity" worth requiring code
this much more complex?

kre

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg