Hi ANIMA,
Some background on the new discussion:
A few of us have been discussing the need to cryptographically sign
GRASP multicasts (especially M_FLOOD messages) and this has shown
up a gap in RFC8990 (the GRASP spec). We're currently thinking that
this topic will need a draft (or maybe two drafts) so this message
is a request for your thoughts.
The ability to sign M_FLOOD (and possibly M_DISCOVER) would be
desirable, because these are messages that cannot be protected by
(D)TLS, which don't work for multicast.
We would prefer that this doesn't invalidate existing (unsigned)
GRASP code. That could be done by appending an optional signature
to the existing M_FLOOD message format. An alternative is to add a new
flood format that is signed, but would not be understood by
existing code.
To summarise a few points:
1. It is feasible to define new GRASP options added at the end of
existing message formats, because the typed nature of CBOR allows
the recipient to decode the message with or without the addition.
(I haven't updated my prototype code but I know how to do it.)
2. However, there would be a problem if the existing GRASP code
treats unknown options as an irrecoverable error. Section 2.8.2 of
RFC 8990 was intended to avoid that, but the CDDL definitions of
individual message types do not allow for unknown options. (That
would need something like adding *grasp-option at the end of the
definition of M_FLOOD.) Depending on whether the existing code
applies the CDDL more or less rigidly, unknown options could
cause failures.
This needs a clarification of RFC8990, and expanded (but
strictly compatible) CDDL.
3. It seems fairly obvious that we should use COSE, most likely
with a detached payload, so that the M_FLOOD message appears unsigned
for nodes that don't support signing and verification.
4. We don't claim to have solved the general problem of key
distribution for multicast destinations, but in the ACP context
it seems likely that we can flood out the necessary public keys.
All comments welcome!
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
