Subject: [Int-area] Comments on draft-bagnulo-multiple-hash-cga-00

From: Christian Vogt <[email-masked]>
Date: Thu, 14 Sep 2006 11:25:47 +0200

Hi Jari and Marcelo,

your proposed changes to change RFC 3971 make sense.  It would be good
to let IPv6 nodes choose a more secure hash function than SHA-1 for
CGA generation.

Two more specific comments, though.  Many thanks to Mark Doll for an
excellent discussion on this.

(1)  Since there are only 8 possible Sec values, wouldn't it make sense
to recycle the semantics of these values over time?

Specifically, if an old CGA SEC registry entry is found to be
insecure, it could be deprecated for a certain (minimum) time, so that
CGA implementations have time to migrate to a more secure combination of
hash function and number of leading zero bits in Hash2.  When there is
need for a new combination, the oldest deprecated registry entry would
eventually get replaced.

Along this line, we could deprecate registry entry 0 (SHA-1 + 0 leading
zero bits in Hash2) today.

Optimally, new CGA implementations should include an interface via which
they could be updated to registry changes.  But since such changes are
expected to occur only at a very low frequency, it may just be
sufficient to pre-configure CGA implementations.

Erroneous use of an obsolete CGA SEC combination would not be dramatic:
 CGA verification would fail in the worst case and nodes would have to
revert to unprotected IPv6 addresses.  But note this would happen only
if the obsolete CGA SEC combination was considered insecure anyway.

(2)  Wouldn't the length of the modifier have to be defined as part of
the CGA SEC registry, too?

If we define the number of leading zero bits for Hash2, say N, as part
of the registry, we are no longer bound to the limit of 16 * (23 - 1) =
112 bits which the 3-bit Sec parameter provides.

However, the length of the modifier should be at least as long as N plus
a certain number of bits for location privacy.  Since this may, at some
future time, exceed the limit of 112 bits, it may be good to define the
modifier length as part of the IANA registry, too.

Alternatively, the length of the modifier could be defined implicitly,
e.g., as:

  |modifier| = max(128, 59 + N)

This ensures that the modifier cannot be shorter than it is today
(i.e., 128 bits), facilitating backward-compatibility for existing CGA
implementations which use a Sec value of 0.

Of course, the current 128-bit length of the modifier is likely to be
sufficient for decades.  It just seems that the prospective revision of
RFC 3972 provides a good opportunity to make this change.

Best,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Sep 2006 10:49:00 +0200

Hi Christian,

i am sorry for the delay and thanks for your comments

see below...

> to recycle the semantics of these values over time?

yes, but my concern is about how much time do we need to start re using 
an previously assigned value safely

> need for a new combination, the oldest deprecated registry entry would

agree but i would like to hear some comments about how long does this 
process take. I mean, i guess that there are quite a few old 
implementations that do not get upgraded and we would need to support 
these.

> zero bits in Hash2) today.

Are you proposing to do this now?
I am not sure that at this point the sec = 0 is unsafe... Do you have 
some information about specific threats with this Sec= 0?

> if the obsolete CGA SEC combination was considered insecure anyway.

I am not sure about this....

wouldn't this open the doors to downgrading attacks?

I mean, suppose that an attacker wants to hijack a CGA e.g. in SeND.
suppose that the CGA being used contains a Sec parameter that has been 
reasigned. We have the old parameters associated with the Sec value and 
the new paramters
suppose that the attacker can crack the old paramters but not the new 
ones
so, the attacker will send SeND validation information using the old 
paramters and the receiver will beleive that this is just an old 
implementation that has not been upgraded, so the attack can succeed...

Now, the alternative would be to simply not accept the old paramter 
information as valid, but this would break interoperation, hence we 
need very long periods of time for changing reasigning a sec value.

So, i would preffer delaying the reassignemet of sec values as much as 
possible, in particular, till we run out of sec values. Then we could 
start reassigning the initiallly assigned values (or other values that 
had prooved not to be widely implemented)

OTOH, i am not we need to do anything in the draft in order to support 
this... I mean AFAICT is a matter of the registry administration and we 
will need to deal with this when we run out of Sec values, i guess...

> modifier length as part of the IANA registry, too.

I think this is a good point, indeed

However, I am not sure this needs to be encoded in the address itself 
i.e. in the sec value itself. I mean the only reason to encode 
information in the address itself AFAICS is to prevent downgrading 
atttacks, agree?

that is why we need to encode the hash function there.

However, i am not sure this is the case for the length of the modifier. 
I mean, would an attacker benefit from having a shorter modifier? would 
this make any attack easier for him? I can not see any downgrading 
attack related to this... can you?

I mean, in case we need longer modifier, we can just define a extension 
to the cga that indludes additional modifier bits, but my point is that 
i don't see the need for coding the existance of a longer modifier in 
the address itself

thanks for your comments, regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 Sep 2006 11:39:59 +0200

Hi Marcelo,

thanks for the feedback!  Responses in-line.

>> (1)  Since there are only 8 possible Sec values, wouldn't it make 
>> sense to recycle the semantics of these values over time?
> 
> yes, but my concern is about how much time do we need to start re 
> using an previously assigned value safely

Keep a registry entry considered insecure deprecated as long as
possible.  Re-use it only when a new registry entry is needed, but all 8
available Sec values are occupied.  In that event, re-use the oldest
deprecated registry entry.

>> insecure, it could be deprecated for a certain (minimum) time, so 
>> that CGA implementations have time to migrate to a more secure 
>> combination of hash function and number of leading zero bits in 
>> Hash2.  When there is need for a new combination, the oldest 
>> deprecated registry entry would eventually get replaced.
> 

See above.  We only re-use registry entries as a last resort.

Note that a CGA implementation that is hard-coded for a stale registry
entry uses insecure/broken cryptographic functions anyway.  This means
that it does not matter that much if such an implementation falls back
to standard IPv6 if it turns out that it is incompatible with a more
up-to-date implementation at a peer.

>> Along this line, we could deprecate registry entry 0 (SHA-1 + 0 
>> leading zero bits in Hash2) today.
> 
> Are you proposing to do this now? I am not sure that at this point 
> the sec = 0 is unsafe... Do you have some information about specific 
> threats with this Sec= 0?

I'm not saying there are existing threats for Sec=0.  Deprecating the
value now would simply ensure that new CGA implementation default to a
more secure hash function.

>> Optimally, new CGA implementations should include an interface via 
>> which they could be updated to registry changes.  But since such 
>> changes are expected to occur only at a very low frequency, it may 
>> just be sufficient to pre-configure CGA implementations.
>> 
>> Erroneous use of an obsolete CGA SEC combination would not be 
>> dramatic: CGA verification would fail in the worst case and nodes 
>> would have to revert to unprotected IPv6 addresses.  But note this 
>> would happen only if the obsolete CGA SEC combination was 
>> considered insecure anyway.
> 

I don't think so.  See below.

>  suppose that the CGA being used contains a Sec parameter that has 
> been reasigned. We have the old parameters associated with the Sec 
> value and the new paramters suppose that the attacker can crack the 
> old paramters but not the new ones so, the attacker will send SeND 
> validation information using the old paramters and the receiver will 
> beleive that this is just an old implementation that has not been 
> upgraded, so the attack can succeed...

We have to ensure that a CGA implementation does never accept two
different parameter sets for the same Sec value.  Only this would allow
for downgrading attacks.

> need very long periods of time for changing reasigning a sec value.

Right, the timeout periods have to be very long.  But if we do not allow
for re-use after such a long period, then we would eventually run out of
registry entries.  There are only 8 available.

And note we must use the 8 Sec values to encode BOTH, a hash function
and a number of leading zeros for Hash2.  While the hash function may
have to be replaced only very rarely, we may have to increase the number
of leading zeros for Hash2 more frequently, requiring a new Sec value
each time...

> So, i would preffer delaying the reassignemet of sec values as much 
> as possible, in particular, till we run out of sec values. Then we 
> could start reassigning the initiallly assigned values (or other 
> values that had prooved not to be widely implemented)

This is what I was proposing in my email.

> OTOH, i am not we need to do anything in the draft in order to 
> support this... I mean AFAICT is a matter of the registry 
> administration and we will need to deal with this when we run out of 
> Sec values, i guess...

It would be good to specify the intent for re-use in the draft so that
sophisticated CGA implementations could provide an interface via which
they can be updated to registry updates.

The current CGA standard also includes the option of falling back to
standard IPv6 in case the correspondent node does not support (or claims
not to support) CGAs.

>> (2)  Wouldn't the length of the modifier have to be defined as part
>>  of the CGA SEC registry, too?
>> 
>> If we define the number of leading zero bits for Hash2, say N, as 
>> part of the registry, we are no longer bound to the limit of 16 * 
>> (23 - 1) = 112 bits which the 3-bit Sec parameter provides.
>> 
>> However, the length of the modifier should be at least as long as N
>>  plus a certain number of bits for location privacy.  Since this 
>> may, at some future time, exceed the limit of 112 bits, it may be 
>> good to define the modifier length as part of the IANA registry, 
>> too.
> 

I wasn't saying that the length of the modifier needs to be encoded into
the CGA, but it should rather be defined as part of the registry entry.

If we define the modifier length in the registry entry, then CGA
verifiers can see how long the modifier field is when they
recompute/verify a given CGA.

I do agree that there is no possibility for downgrading in this case.

> that is why we need to encode the hash function there.

Yes.

<snip>

Alright, best regards,

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Sep 2006 12:44:48 +0200

> deprecated registry entry.

or the less used entry i.e. suppose that one assignment was made that 
was not successfull at all for any reasons (like IPv5 for instance)

> See above.  We only re-use registry entries as a last resort.

agree

> I'm not saying there are existing threats for Sec=0.

but then there is no point in deprecating it imho
I mean, as i see it, we need to deprecate an entry because it is no 
longer safe to be used, not because there are stronger options... 
agree?

>   Deprecating the

> they can be updated to registry updates.

i don't have a problem with including a section with this.

does anyone else has an opinion on this? Jari?

basically the additional text would to state that:
- since there are few sec values, it may be needed to reuse sec values
- this is a last resource option, since it may affect interoperation
- a long time is required between the deprecation of the old value and 
the reassignment in order to prevent misinterpretation of the value by 
old implementations
- this may affect interoperation (if an old implementation receives a 
CGA  generated with the new meaning of the sec value, it will fail)
- by no means an implementation should support both meaning of the Sec 
value, since it may lead to downgrading attacks,

anything else needed in this section?

> the CGA, but it should rather be defined as part of the registry entry.

You mean like additional information...

I don't know...

i guess that if a new sec value is assigned, the details will need to 
be defined in a RFC so i would say that the RFC would be right place to 
describe all the related information, including the modifier length for 
this particular sec value... i mean, as you mention, current 128 bit 
modifier seems to be good enough for our needs now...

Summarizing, i don't have a strong opinion on this neither, but i think 
it would be easier/simpler to store this information in the associated 
spec and reduce to the minimum the information contained in the 
registry itself.

does anyone else has an opinion?

thanks again for your comments, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 Sep 2006 15:23:47 +0200

> was not successfull at all for any reasons (like IPv5 for instance)

Ok, although it might in general be difficult to decide which registry
entry is used the least.

<snip>

Yes.

<snip>

> anything else needed in this section?

This seems sufficient IMO.

Yes.

> does anyone else has an opinion?

Hmm, the necessary length of the modifier follows directly from the
number of leading zeros for Hash2.  Since this number of zeros is
defined as part of the registry entry, the registry entry also seems to
be the right place to define the modifier length.

Adding more modifier bits to the CGA Parameters data structure in the
form of a variable-length extension field, as you mentioned, would also
be a viable option, because the MN could then decide for itself how many
random bits it needs.

BTW, will there /always/ be an RFC for each new registry entry?

Bye,
- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Sep 2006 15:40:54 +0200

> This seems sufficient IMO.

ok, i will wait for additional comments in this topic, and if no 
opposition i will include some text in the next version

> defined as part of the registry entry,

this is not the case, actually

The registry only contains the name, the sec value and the RFC where 
the sec value usage is defined

the number of zeros in the hash2 will also be defined in the RFC that 
defines the sec value usage

that is why i suggest to define the modifier length in the RFc that 
defines the SEC value also

>  the registry entry also seems to

> BTW, will there /always/ be an RFC for each new registry entry?

yes, the IANA considerations states

"future assignments are to be made through Standards Action [2]."

thanks, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 Sep 2006 15:55:10 +0200

Marcelo,

given that the registry entries are simply pointers to more detailed
RFCs, yes, I do agree that the modifier length should be defined in
those RFCs.

Nonetheless, I think that CGA implementors should be prepared for the
possible change in the modifier length by some text in your and Jari's
draft.

Best,
- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 19 Sep 2006 16:13:21 +0200

> possible change in the modifier length by some text in your and Jari's

Ok, i will include some note about this

Regards, marcelo