Re: [core] Comments on draft-ietf-core-object-security-06

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Göran Selander [mailto:[e-mail]]
> Sent: Friday, December 02, 2016 12:31 AM
> To: Jim Schaad <[e-mail]>; draft-ietf-core-object-
> [e-mail]
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-core-object-security-06
> 
> Hi Jim,
> 
> Thanks for your comments. The subject of this thread should of course be
> "Comments on draft-ietf-core-object-security-00”.

I think the -06 is left over from looking at the EDHOC document.  You are completely correct it should have been -00

> 
> Appendix C, OSCON, is addressing other use cases than OSCOAP, more of this
> below. It has not been progressed lately since we wanted to focus on the
> OSCOAP use cases which seem most relevant at this stage. Also we were waiting
> for Klaus to present his solution, which may overlap with OSCON. I will make
> Github issues out of the comments inline, but we may incorporate those in the
> draft at a later stage since we have a tight time schedule for OSCOAP.
> 
> On 2016-11-30 07:08, "Jim Schaad" <[e-mail]> wrote:
> 
> >
> >Appendix C - I am having a hard time with the first paragraph here.  I
> >do not believe that you have correctly characterized the problem.  The
> >reason that you cannot use OSCOAP for this has more to do with how you
> >decided which records in the header to authenticate rather than the
> >fact that this is going to be distributed to multiple recipients.
> 
> The intended logic is the following:
> 
> The security requirements draft
> https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs currently
> describes three use cases “proxy forwarding”, “proxy caching” and “publish-
> subscribe”. The solutions to these requirements protect as much as is possible,
> while still allowing the functionality of the use case.
> OSCOAP addresses the "proxy forwarding” use case, which is a basic CoAP
> request-response with optional forward proxy functionality. This is a use case
> we have been requested to support, and it is an interesting case also because
> essentially all options and headers that are passed end-to-end in a CoAP request
> and response can be protected, response can be bound to a request, and some
> other security features can be supported.
> 
> OSCON addresses other use cases with a common solution, including the two
> remaining use cases mentioned above. In these cases less of the records can be
> protected, e.g. because a single response should be meaningful to multiple
> requests. This solution thus targets a format where multiple use cases can be
> supported rather than optimising security for a particular use case.
> 
> I will make an issue to clarify this.

It is not the least bit clear to me that publish-subscribe case cannot be done with OSCOAP.  The proxy caching problem is more difficult, but is not solved by OSCON in a way that is not also solved in the OSCOAP case as far as I can tell.

> 
> >
> >Appendix C - Talking about the "unprotected" and the "protected" CoAP
> >message is very confusing especially since COSE has protected and
> >unprotected objects as well.  It would be better to use a different
> >terminology such as "the original message" and "the resulting message".
> 
> This terminology is defined in the body of the draft. (FWIW the terminology
> probably predates COSE.) If we always qualify with unprotected/unprotected
> CoAP, protected/unprotected COSE header, I suppose there would less of a risk
> for misunderstanding?

Doing the full qualification would be nice.  I will admit that I probably missed that since I started half way down the document.

> 
> >
> >Appendix C - I do not understand what this sentence means. " OSCON
> >shall not be used in cases which require a secure binding between
> >request and response."  Is it intended to say that the use of a
> >transaction identifier in the COSE wrappers for the request and
> >response is not permitted?  There are a lot of ways to do this that do
> >not rely on CoAP.
> 
> As mentioned, this format is addressing use cases which does not bind response
> to request. It is possible to define a wrapping of a message exchange in COSE
> which has different features, but that was not the intention here.

This is not making it any clearer to me. 

> 
> 
> >
> >Appendix C - It is not clear if the Content-Format should be set if
> >there was no Content-Format in the original message.
> 
> It should, to be clarified.
> 
> >
> >Appendix C.1 - I do not understand what this section is trying to
> >accomplish.  It appears to be doing three different things, some of
> >which should be in Appendix C, some of which should be standalone and
> >some of which looks like it should be
> 
> It is an introduction to sections C.2-C.5. We should clarify that.

Making C.2-C.5 be sub sections would probably also help

Jim

> 
> >
> >Appendix C.5 - There should be a discussion related this this about the
> >different security properties that are to be found for Encrypt+Sign(M)
> >vs Sign(Encrypt(M)).
> 
> There are plans to write more about the security properties of SEAS, probably in
> a different document.
> 
> >
> >Appendix B - These are really example message flows rather than
> >examples of OSCOP messages.  This should be made clearer in the section
> >title
> 
> OK, I’ll make that update in -01.
> 
> >
> >Appendix B.1 - How does one securely bind the request and the response?
> >I am not seeing anything from this example that will do so.
> 
> No, it is not visible from the message format. See section 6.1 "the response is
> verified to match a prior request, by including the unique transaction identifier
> of the request in the Additional Authenticated Data of the response message."
> 
> Göran
>