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

["Bernie Volz (volz)" <volz at cisco.com>]

That spec detail I included was from SEND RFC and the length field there
is counting multiples of 8.

DHCPv6 option length fields are 16-bits, so not to worry. (If this was
for DHCPv4, more of a concern, but then there's Ted's RFC that can allow
multiple instances of the option to be concatenated. But v4 is not on
the table at present.)

- Bernie 

-----Original Message-----
From: kre at munnari.OZ.AU [mailto:kre at munnari.OZ.AU] 
Sent: Monday, July 14, 2008 2:22 PM
To: Bernie Volz (volz)
Cc: dhcwg at ietf.org
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome! 

    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