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

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Christian Amsüss <[e-mail]> 
Sent: Wednesday, August 5, 2020 12:03 PM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; 'Core WG mailing list'
<[e-mail]>
Subject: Re: [core] Review draft-amsuess-core-cachable-oscore-00

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"?

[JLS] I was thinking of the first one  I don't know that the second one is
possible until we have a better idea.

> *  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).

[JLS] The ever popular - I changed things so this is moot ploy. [1]  Need to
see it written down but I think it is equivalent.

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.

[JLS]  I am not sure why it would matter in some respects.  If the response
is going to be more individual then either you are going to get a unique
deterministic request or not use it at all.

Jim


KR
c

[1] See "The Pink Panther"
--
To use raw power is to make yourself infinitely vulnerable to greater
powers.
  -- Bene Gesserit axiom