Re: [T2TRG] RESTful Design & Security

[Hannes Tschofenig <[e-mail]>]

Hi Carsten,

an additional consideration is that confidentiality protection of the
payload still reveals a lot of information about what is being accessed
via the URI.

Ciao
Hannes

On 03/08/2017 11:08 AM, Carsten Bormann wrote:
> On 8 Mar 2017, at 09:30, Göran Selander <[e-mail]>
> wrote:
>> 
>> 1. Apply security above the web transfer layer, i.e. to CoAP/HTTP
>> payload, e.g. by wrapping the payload in the COSE format. In this
>> case the secure COSE object is independent of web transfer
>> mechanism so you can switch between e.g. HTTP and CoAP. However,
>> the web transfer metadata, including e.g. the RESTful method,
>> resource etc. is not protected. This is anyway useful if the
>> method/resource etc. is implicit or the application provides the
>> context, e.g. CoAP pub/sub.
> 
> Apart from the HTTPS straightjacket I just discussed, this is the
> other interesting design issue about RESTful security.
> 
> Should we design all objects being interchanged in such a way that
> they can be signed by themselves, which implies that they don’t need
> context to interpret them?
> 
> E.g., if I
> 
> GET coap://bathroom.cabo.space/temperature
> 
> a typical result in a REST world might be a CBOR or JSON object
> saying
> 
> [{"u":"Cel","v":23.125}]
> 
> But there is no point in signing that object by itself; it does not
> mean anything useful.
> 
> A signed object would need to include the fact that this is about my
> bathroom, and some freshness information (such as the current time).
> If you don’t want to use absolute time for freshness, you would
> include a request nonce, which makes this object useless for a
> different request, so you might as well bind it to the request in
> other ways (e.g., include the URI instead of some generic semantic
> information tying this to my bathroom).
> 
> The OSCOAP approach is to simply bind responses to the relevant
> information in the request, so all this happens “automatically” (you
> wish).
> 
> Grüße, Carsten
> 
> _______________________________________________ T2TRG mailing list 
> [e-mail] https://www.irtf.org/mailman/listinfo/t2trg
>