[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!
>Can you however point at existing implementations
>where it is not added last?
Yes, the Cisco Network Registrar DHCPv6 server does not necessarily add
the AUTH option last -- it will add the AUTH option and then any options
requested by the client. The server adds the option and then, just
before sending the packet, does a callback to a function that is
responsible for calculating the hash and storing it into the buffer to
be transmitted.
>Yes, absolutely - as I said, there's no technical reason at all for
>requiring the option to be last. Just pragmatics.
OK, great. I have no issues if an implementation actually adds it last,
but I do have an issue with a I-D/RFC that would require it to be last.
>That's not true for a public key signature, or not in the way I think
>you mean anyway. The size of the signature depends upon the key used,
Sure, you have to know the key to figure out the signature size.
Again, an implementation should be free to implement this any way it
wants. If the implementation wants to add the option last, that is its
choice. But not something that should be required.
- Bernie
-----Original Message-----
From: kre at munnari.OZ.AU [mailto:kre at munnari.OZ.AU]
Sent: Monday, July 14, 2008 6:33 AM
To: Bernie Volz (volz)
Cc: Sean Shuo Shen; Mark Stapp (mjs); Sheng Jiang; dhcwg at ietf.org
Subject: Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted. Comments are welcome!
Date: Sun, 13 Jul 2008 23:37:13 -0400
From: "Bernie Volz (volz)" <volz at cisco.com>
Message-ID:
<8E296595B6471A4689555D5D725EBB21080C9F16 at xmb-rtp-20a.amer.cisco.com>
| The current AUTH option does not have to be last
Yes, I understand that. Can you however point at existing
implementations
where it is not added last? If not (unless there simply no
implementations
at all) that kind of proves my point. If there are some, I'd really
like
their authors to explain why they implemented it that way.
| and the message can be constructed (and validated) just fine
Yes, absolutely - as I said, there's no technical reason at all for
requiring the option to be last. Just pragmatics.
| - yes, the hashed data is added
| into at the end of message construction but that is not an issue as
the
| hash is always a fixed size.
That's not true for a public key signature, or not in the way I think
you mean anyway. The size of the signature depends upon the key used,
and not at all upon the data being signed (ie: you generate a 128 bit
hash of the message, the signature is still 1024 bits, plus overheads,
for a 1024 bit RSA key - at least for RSA public keys, I'm less sure
about the other algorithms, but I suspect similar there, and in any
case,
for CGA's, which were under discussion here, RSA is the only option
right
now).
That is, it may be true that the signer can work out how big the
signature
will be, in advance of calculating it, but it's sure easier to just
generate
it, and then see how big it is. There's certainly no constant size
that you
can assume the signature will be before you look at the particular key
pair.
kre
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg