Malisa Vucinic <[email protected]> wrote: > From the point of view of code reuse, DTLS seems to make sense but I > think we would really need to find a way of getting rid of 10+ packets > to get things going, particularly when we can leverage PSKs. Looking at > draft-ietf-dice-profile, it seems that session resumption could help us > for that. I am thinking whether it would make sense for the JN to > initiate the handshake using session resumption without server-side > state (RFC 5077) and get the handshake done in 1.5 exchanges when PSK > is in place. Or in case we decide that JN should be a DTLS server and
It's something that I considered as well, except that I would reverse the
negotiation. Have the JCE initiate to the JN (the JA relays packets).
The process could look like this:
1) JA lets the JCE know of it's existence (TBD)
2) JCE talks to vendor, gets stateless session-resumption token from
vendor. That's an entire protocol, but it's a protocol that doesn't
need to run over the LLN... and the data could instead be delivered
by USB key, or QR code... clearly it needs to be remain confidential.
3) JCE initiates to JN, JN decrypts state.
There are some issues with this. Essentially, the entire process is really
protected by the symmetric key that the JN uses to create it's stateless
token. And the tokens wind up being bearer tokens... whether the tickets are
resuable depends upon how they are made, I think. If there is more than one
of them, that's another question, but they can be produced by the
manufacturer in a situation where there is lot of power, or the key is
available, etc.
--
Michael Richardson
-on the road-
pgp3wEaiJWKDZ.pgp
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
