On Tue, Aug 30, 2022 at 06:26:41PM -0400, Michael Richardson wrote:
> bc> Right. So I'm not yet convinced we should repurpose the session ID for
> bc> this. If we're going to focus on signing objectives, maybe we need to
> bc> decouple this aspect completely from the session ID?
>
> I am sitting on the fence still here.
> I think that during flooding, that the whole point is to replay the object
> until all interested parties have seen it :-)
In my prior email i pointed to the attack problem: turning session-id into
a sequence number with initial random value would allow attackers to
"pre-flood" near-term session-id values and therefore prevent the valid
messages with this session-id to reach (some of) their destinations.
However, this issue only exists when grasp forwarders do not check signatures.
If they would check signatures, they would recognize the attack messages.
But checking signatures is asymmetric crypto == expensive. However, we need
ultimate receivers to do it too. And forwaders typically are also ultimate
receivers.
Aka, imho, our choices are:
a) Make flood-message forwarders check signatures, we create a more
secure flooding, but with more performance considerations, and we can avoid
having to create another message element, session-id will suffice.
b) Do not make forwarders check signature. we need to introduce another
"sequence-number" element that is not used for flooding, but only for
replay protection.
> Aside from the anti-replay aspect, it would be nice to be able to avoid
> having to have a cache of every flooded message since the dawn of time.
> For that reason, it's probably good to have an Epoch ID as a separate object,
> so that when it changes, then you can safely throw away your session-id cache.
I have to see in more detail how you think epoch would increase.
Today, GRASP could/should time-out cached session-ids after shortly more than
the time a poor packet could aimlessly be forwarded in the network. For
LLN with really low bitrates i'd say 5 seconds, for any other network 1 secon
(IMHO). This may not cover all implementation error cases, but depending on
how a flood message is used, it does not matter.
Aka: Normal use-case (for me) is a service announcement. If that flood-message
is erroneously repeated by some lost copy being reviewed some time later, not
a big deal. If its stale information, whoever needs the service will still
have other means at that time to figure out the service does not work anymore.
However, if you where to use flood-message to flood IoT instructions, such
as "all emergency lights in build, toggle your state". And then that
message gets partially received twice on some receiver nodes, and then some
part of the building emergency lights are off and others are on. Granted:
This is exactly how you MUST NOT design a multicasted action system, and
its easily avoided by having the action not say "toggle", but "on" or "off",
and then again unnecessary replication of the message is just a waste of
processing resources but does not impact outcomes.
> I'd argue for always checking signatures if they are there before flooding.
> If it's too expensive, then I think that I'd rather lower the strength of the
> signature until it's cheap enough. If it's a thing that has security
> critical information, then if some ASA finds that the signature is too weak,
> then it could just do some unicast GRASP with a stronger signature.
That one paper from Thomas' Schmidts team about crypto performances that i had
in a prior mail here did not seem to show me that low-end
IoT will actually be faster when the asymmetric crypto has longer or shorter
keys. Maybe you can ask them next week, when you're in Hamburg about this,
else i will remotely. It seems logical to me that lower strength crypto should
be cheaper, but then there is this weird reality of HW chip implementations
that seems to contradict what seems to be logical.
But lets assume it is correct. So we use weak asymmetric crypto, just strong
enough
to survive attacks for period of time shorter than some hmm: 1 minute ? And
then we either assume clock synchronization more accurate than that, and/or
introduce some form of epoch ticker that updates once a minute ?
Which then raises the question: How weak can asymmetric crypto be to safely
survive 1 minute ?
Cheers
Toerless
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
