[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!
Date: Mon, 14 Jul 2008 14:04:58 -0400
From: "Bernie Volz (volz)" <volz at cisco.com>
Message-ID: <8E296595B6471A4689555D5D725EBB21080CA1A1 at xmb-rtp-20a.amer.cisco.com>
| Actually, I suspect that both client and server have to deal with it as
I knew that using "client" was touchy - I mean the receiver of the option,
whatever role they play in the DHCP exchange. "client" was just easier
to type. Apologies...
| For a received packet, the node would already have had to find the
| location of the option containing this data and it also has the length
| (of the option as well as the packet). So, to skip to the end of the
| option isn't exactly rocket science (start of option + sizeof(unsigned
| short) + sizeof(unsigned short) + length of option data).
No, it's not, but do you want to imagine the number of off by one type
errors code like that has experienced over history - like does the code
remember the length field does, or does not, include the size of the
length field itself, ... (as you write it above, clearly it doesn't,
but in other usages, it does, and implementors get confused...) And
if in practice there's never anything there, the bug lies dormant.
That's what I was most worried about.
| When sending a packet, putting the packet together is a bit more complex
| if the option isn't at the end, especially if the size of the field
| isn't known. But again, that is an implementation issue and left to the
| implementer - it can always be added "last" or dealt with by moving the
| parts of the data around.
Yes, I am not so much worried about the sender, which can do things as it
desires - though as I started to say in the paragraph I didn't finish typing
I now realise, ideally you don't want the private key to be in use more than
it needs to be, so requiring it to be accessed twice, once for a length
calc, and once for the sig calc, seems like just bad design.
But this is the kind of thing that someone who really understands the security
issues should be examining, and that is certainly not me.
kre
ps: really for the last time, unless of course I get a question I must
answer...
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg