Hi Marcelo,
I don't know if when are up to do packet fragmentation in order to
support more Public Keys or if there is even a need for that.
couldn't parse this one....
I just meant to say: if we want for some usage more that 10 keys, we
might have to handle/use NDP packet fragmentation. NDP packet
fragmentation may be undesired here, but we have may have to state it
explicitly.
> well, it seems that in order to support crypto agility we will need some
> shanges in send.
> whether these particular set of changes is the right one, it is up for
> disucssion, but updating rfc3971 is clearly needed imho
OK, we will propose changes and see if they reach a consensus.
ok, i understand that you will include an high level overview of these
changes in the draft you are writing?
Yes.
> > If not, we can as well use the Key Hash to determine which Public Key
> > in
> > the
> > CGA PDS was used to perform the Digital Signature, but we think it is
> > neither
> > really optimal (as the node may have to compute a lot of extra
> > hashs) nor
> > elegant.
> >
> > > The main issue here is that we need a mechanism to deal with the
> > case > that different nodes support different algorithms.
> > We address this problem by introducing a new SEND option named
> > "Supported Signature Algorithm Option" (name it itself being clear):
> >
> > 0 1 2 3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Type | Length |R| Nr. supp. Algos | Reserved |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | Sig. Alg. 1 | Sig. Alg. 2 | Sig. Alg 3. | Sig. Alg 4. |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > ~ ~ | ... |
> > ~ ~
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > | ... | Sig. Alg. N |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > This option contains signature algorithm that are supported by a
> > node.
> > The receiver can determine which Signature Algorithm is more suited
> > for
> > the emitter.
> what does supported means?
> does it means that it can validate using this suite or does it means
> that it has CGA and or a cert that it uses this suite?
> these are different things and i think we need both?
We need both to perform negotiation process.
well, it depends how you define the nogotiation process, right?
Yes.
> mmm, but the point is that if the attacker can drop ONE packet and fake
> the error message, it would render send inactive between the nodes for
> as long as the information is stored in the cache (Which can be a long
> time if the nodes talk to each other frequently)
Maybe a node shouldn't store/update a cache when it can't talk to a node.
Does it serve a purpose ?
but in this case it was able to talk to him and he obtained a reply that
contains the error message
So, i guess that you are suggesting is that we don't cache the error message
when it is not secured...
I guess we need to check how send works when dealing with plain ND messages,
I understand that SEND always rewrites plain ND, but i don't rememebr how
this works when ND has a cached data....
What I wanted to say was: the attacker can drop some ND packet, so he
can virtually drop anything. If he block on NDP packet and send an error
message in order to shutdown a communication, I don't see any difference
(the new attack effects are not worst if we consider that we won't
update any cache upon reception of an untrusted error message).
> So, this would imply that dropping one packet and generating an error
> message (which is unprotected) would deactivate send between two
> nodes... right?
The error message should be protected (so a third party can check the
message during forensic).
how?
the whole point of the error message it to handle the case that there is no
common crypto suite between the two communicating nodes
So, by definition, the receiver cannot validate the error message
The receiver might not, but a third party could. An administrator could
place probes inside his network that will tell him an attack is
undergoing.
Note that the message could be understood by
the node. If the error message only state something like "you are using
too short keys", it wouldn't prevent the receiver to verify the message.
right, in this case i agree
but this opens the door to downgrading attacks though
I mean, would the error would sign by the long key or the short key?
The short key error in this case is caused by the node that will receive
the error. But it is true that it might be difficult to trust the error
message in some cases.
Regards,
Tony Cheneau
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
