Re: [core] Review draft-amsuess-core-cachable-oscore-00

[Christian Amsüss <[e-mail]>]

Hello Jim,

thanks for your review!

On Fri, Jul 17, 2020 at 04:18:33PM -0700, Jim Schaad wrote:
> I will admit that I found what was proposed here to be very interesting.  I
> am unsure of how well it would work and think that we may want to workshop
> it at some point just to figure that out.

Are you thinking in the direction of "let's think through concrete
exchanges", or "let's try this out with a prototype implementation"?

> *  Reading this document made me really long for an OSCORE padding document
> where the message can be predictably padded out to fixed length so that it
> would make one of the issues raised in this document moot.

Good point -- it'd be generally useful but particularly so here.

Would be typical Appendix material.

> * One wonders about the goodness of returning both a "This is what the
> deterministic request says and here is the encoded request but you cannot
> decrypt it".  It does mean that you need to have a degree of trust for the
> server not lying to you but would potentially allow for an even shorter
> request.

That shouldn't be the case. Any consensus request the client receives
must be readable for the client, otherwise as you say it makes little
sense.

Any hint to such behavior would be an error in the document -- but I
take that point as a cause to point out the importantce of reading it to
the client in the Consensus Request definition.

> * It might be worthwhile to signal that you are going to ask a lot and use
> an application/multiple-coap content to return both the answer and the
> deterministic request.  This means that it would not be cached until the
> next ask but that is going to be true anyway if the server is providing this
> request.

I think that this becomes largely moot with the addition I announced at
the meeting (where the client would send a hash of the plaintext in an
outer option). In such a setup, the client already gives the server a
hint as to the desire for a consensus request and response. (When the
client uses a deterministic request, it can start the process as well).

On the long run, I expect that indication will rather be needed in the
other direction: A client may not know for which requests it is part of
a swarm and which are more individual. In that direction, it may work to
have a target attribute in the link that asks a client to generate a
deterministic request if its security policies allow that.

KR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom