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

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

And, what if there is another option that states it needs to be last?

If there is no technical reason, then drop the requirement. If it makes
it easier to implement, that is up to the implementation to decide to
do; not up to the standard to mandate it.

- Bernie 

-----Original Message-----
From: Sean Shuo Shen [mailto:sshen at huawei.com] 
Sent: Monday, July 14, 2008 8:51 AM
To: kre at munnari.OZ.AU; Bernie Volz (volz)
Cc: 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!

About the "last option" argument, as Kre said, there is no technical
reason
that such a requirement absolutely has to be satisfied, but such a
requirement can make implementations uniformly easier. 

Regard,

Sean



> -----Original Message-----
> From: kre at munnari.OZ.AU [mailto:kre at munnari.OZ.AU]
> Sent: Monday, July 14, 2008 6:33 PM
> 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