Re: [CGA-EXT] One more bit for hash information in CGAs? ( was [Fwd: [BEHAVE] Modified EUI-64 format]

[Tony Cheneau <tony.cheneau at it-sudparis.eu>]

Hello,

I agree too that it would be nice to extend the hash size, even for 1 bit. 
However, I am not sure that it should motivate a break in the backward 
compatibility. I mean, even if there is not wide deployment of SEND, 
other documents rely on the format of the CGA (HBA, RFC 5535 for example).

Maybe a change similar to RFC 4982 modifications could redefine the SEC
bits to indicate: number of bits for the hash2, the hash function and
the CGA version (indicating if "g" bit is used, and maybe more). Only
values 0 to 2 are currently used, leaving 5 values free to be assigned.

Regards,
	Tony

On Tue, 7 Jul 2009, Sheng Jiang wrote:

> Agreed. I think it is useful. Since the hash length is really limited, every
> bit is cherish and important. One more bit means, in average, attackers have
> to double their efforts in order to break the same CGA. This update suits
> CSI charter well as we target to update SEND and CGA specifications from the
> beginning of this CSI WG.
>
> The only issue we need to solve is the complicite backwards compatibility.
> Since we cannot indicate whether this is CGAv1 without g bit or CGAv2 with b
> bit, we may have to fully abandon CGAv1 in the updating process. Personally,
> I think it is fine through it requests all existing implementation changed.
>
> Best regards,
>
> Sheng
>
> > -----Original Message-----
> > From: cga-ext-bounces at ietf.org
> > [mailto:cga-ext-bounces at ietf.org] On Behalf Of marcelo bagnulo braun
> > Sent: Tuesday, July 07, 2009 2:58 AM
> > To: cga-ext at ietf.org
> > Cc: Dave Thaler
> > Subject: [CGA-EXT] One more bit for hash information in CGAs?
> > ( was [Fwd: [BEHAVE] Modified EUI-64 format]
> >
> > There is an ongoing discussion in BEHAVE ml, where it seems
> > that we could use the "g" bit in order to include hash information...
> > considering that the hash length is one of the key
> > limitations of CGAs, we may consider updating 3972 to use this bit...
> > comments?
> >
> > I attach the extract of the thread below...
> >
> > -------- Mensaje original --------
> > Asunto: 	[BEHAVE] Modified EUI-64 format
> > Fecha: 	Thu, 2 Jul 2009 04:06:21 +0000
> > De: 	Dave Thaler <dthaler at windows.microsoft.com>
> > Para: 	Xing Li <xing at cernet.edu.cn>
> > CC: 	Behave WG <behave at ietf.org>
> >
> >
> >
> > Similarly, with privacy addresses referred to in the draft
> > quote at top, RFC 3041 section 3.2.1 point 3 forces the
> > randomized interface identifier to adhere to this
> > requirement, so that it's a 63-bit random number, not a
> > 64-bit random number.  And with CGAs, RFC 3972 section 4
> > point 6 similarly forces a generated interface identifier to
> > adhere to this requirement. (As an aside, it also reserves
> > the "g" bit which is actually unnecessary since it's not IEEE
> > EUI-64-derived.  RFC 4291 only discusses the "g" bit for
> > addresses derived from IEEE EUI-64's, which is why RFC 3041
> > and a translation format can still use that bit).
> >
> >
> >
> > _______________________________________________
> > CGA-EXT mailing list
> > CGA-EXT at ietf.org
> > https://www.ietf.org/mailman/listinfo/cga-ext
>
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT at ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext