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>

Actually one more message, as I just remembered one more point I forgot ...

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

In practice, no-one cares.   The sender knows how big the sig is, that's
part of the result of the encryption.   It then adds as many padding bytes
as it wants for whatever purpose it needs them - which as an earlier message
from you pointed out, for DHCP, would be none at all, they're not needed.

The receiver (the protocol code that is verifying the signature) just treats
the sig and padding as a single field, and hands it all to the validator.
The validator understands the internal encoding of the sig field, and knows
how to find the length from there, and simply ignores the padding that
follows (I'm not even sure the caller bothers telling the validator the
length it believes the sig+padding occupies, more likely just ptr to sig).

So, in practice, the actual sig length is known where it is needed to be
known, and isn't needed anywhere else.   That is, none of us actually
needs to understand the internal sig encoding, to be able to figure out the
length - we simply don't care (which is one reason that authors of specs
never bother to mention that it exists - if they even realise it).

One thing I would point out from the spec sample you included (packet format).
If the length is 1 byte, and it is counting bytes in the option (I know the
one you quoted is not), then the option won't be able to handle entirely
plausible signatures.   Bigger than 255 bytes happens for keys < 2048 bits...
(not a lot less, but less).

SEND doesn't have that issue, as its length field is counting multiples of 8.
The MIPv6 ERO spec has a bug because of this.   It is something to be aware of.

kre

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