Hi Christian,
i am sorry for the delay and thanks for your comments
see below...
El 14/09/2006, a las 11:25, Christian Vogt escribió:
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?
yes, but my concern is about how much time do we need to start re using
an previously assigned value safely
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.
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.
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?
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 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...
(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 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
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 protected]
https://www1.ietf.org/mailman/listinfo/int-area
