Re: [6tisch] Review of draft-ietf-6tisch-minimal-security-06

[Mališa Vučinić <[e-mail]>]

Hi Klaus,

Your email somehow ended up being classified as Spam by Google's filter and
I found it only after explicitly searching for it in the Spam folder.

As discussed offline, we are happy in 6tisch to make this functionality
useful for the general-purpose CoAP in collaboration with CoRE.

Let's discuss further during 6TiSCH today and in the next days.

Mališa

On Fri, Jun 29, 2018 at 10:21 PM Klaus Hartke <[e-mail]>
wrote:

> I've reviewed draft-ietf-6tisch-minimal-security-06, focusing on the parts
> that involve CoAP.
>
> The Stateless-Proxy option is interesting. When a CoAP client (or proxy in
> the role of a client) makes a request, it usually has some state
> information at that point in time and requires that information to continue
> where it left off when receiving the response. CoAP facilitates this by the
> Token: an opaque value that is sent along the request and echoed back
> verbatim in the response.
>
> When the Token was designed in the CoRE working group, we had a discussion
> if the token value should just serve as an identifier for the state
> information stored at the client, or if the client should be enabled to
> encode information directly in the token, protected by an authentication
> tag, which would allow the client to continue where it left off without
> keeping any state information in the meantime. Since we didn't have a
> specific use case at that time, the (non-reversible) decision was made to
> not allow it and to limit the token value to a maximum size of 8 bytes.
>
> The Stateless-Proxy option overturns that decision. While I think that the
> original decision was not the best, this is really unfortunate. Not only
> are there are now two tokens in a message, which doesn't help with keeping
> the protocol simple and easy to understand; the new token is also not even
> always echoed back.
>
> I don't see why a protocol extension is needed in the first place. It
> seems the current functionality could be achieved equally as well by
> passing the state information in the payload [1].
>
> Seeing that Tero also has some comments on statelessness, I think that
> this part needs more work.
>
> The other parts involving CoAP look good to me. (The prescribed URI path
> "j" is a bit suspicious since it conflicts with BCP 190, but might be fine
> because of the "6tisch.arpa" authority.)
>
> Klaus
>
> [1] E.g.: JP receives request from pledge, wraps that request and state
> information in a new payload, makes request with that payload to JRC,
> receives a response from JRC, unwraps response to pledge and state
> information from response from JRC, sends response to pledge.
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>