Subject: Re: [core] Comments on draft-selander-ace-objet-security-05

From: Francesca Palombini <[email-masked]>
Date: Thu, 27 Oct 2016 10:04:50 +0000

Hi Jim!

Sorry for the late reply. 

We have updated the draft and included most of your comments (in a satisfying way I hope).
You can check either on the github: https://github.com/EricssonResearch/OSCOAP (I included your comments in the issues: 16 to 21, 24) or in the latest version of the draft: https://tools.ietf.org/html/draft-ietf-core-object-security-00 

The remaining 4 points (see below) I'd like to discuss with you, face to face in Seoul, if possible! Let's take it offline.

Francesca

> > -----Original Message-----
> > From: Jim Schaad [mailto:[email-masked]]
> > Sent: den 31 augusti 2016 02:51
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Comments on draft-selander-ace-objet-security-05

1. pub-sub

> > Introduction:  Given the scope of the analysis, I do not believe that
> > you
> can
> > restrict your solution to just dealing with the forwarding case.
> > Specifically I think you need to deal with the pub/sub cases with or
> > w/o
> an
> > agent.
> >
> > [FP] the pub/sub case should be dealt with by OSCON (Object Security
> > of Content - Appendix C), in which only the payload of the message
> > would be protected, not the entire request-response exchange. We
> > really meant
> OSCOAP
> > as a challenge-response protocol (mentioned first in the abstract
> > "OSCOAP provides (...) a secure binding between CoAP request and
> > response
> messages").
> > Other scenarios (such as multicast with unicast response) can be used
> > with OSCOAP, with some adjustments (this is a work to come soon).
> 
> This may be an issue with how the document is arranged then.  I don't know
> that it makes sense to have OSCON be in an appendix if it is expected to be
> used in such a major situation as pub/sub.  Being in an appendix makes it be
> low priority in my mind as being not too useful.

2. caching

> > Section 2 - I am not sure that the SHOULD NOT on caching makes
> > complete sense.  It would make sense to cache the response if correlated
> to the
> > original request for reliability.   Caching also makes sense in the
> pub-sub
> > world
> >
> > [FP] I am not sure I understand this comment. What do you mean by "for
> > reliability"? If you talk about message re-transmission, that's on
> > CoAP
> message
> > layer or a lower layer than CoAP neither of which are in scope of OSCOAP.
> 
> Caching is part of what allows for re-transmission and reliable sending in my
> mind.  I realize that this may not be a general feeling, however if a response
> is cached then the re-transmission can be short circuited at the cache rather
> than needing to go all the way back to the responder and thus having the
> same problems with getting the response all the way back because of
> collisions and time outs.
> 
> When I say reliable transmission I am talking about it in the same sense as
> does RFC 7252 which is the CoAP specification.

3. token - transaction id association during retransmission

> > Section 3.2 - There is a fun thing that needs to be thought about.  A
> client which
> > sends a token along with the request may try and register the same Cid
> more
> > than once because the response to its request may get lost.  This
> > needs to
> be
> > documented potentially as saying that the same Cid must result in the
> > same context being generated.
> >
> > [FP] I don't understand what you mean by "register the Cid", and what
> token are
> > you talking about here. Could you expand?
> 
> By register the Cid, I mean put it into the key table that I am maintaining.
> 
> Client                        		Server
> Send request		--> 	receive and process
>                 ||blocked    	<--  	send response
> 	|| or lost
> Resend same request   --->          receive and process --
> 		what do I do about the duplicate Cid???
>                              Error or return the same response

4. sequence number

> > Section 5 - Your maximum sequence number is going to be much smaller
> > than 2^56-1.  You need to factor in the reduced sized tag and the
> > limits for
> GCM into
> > this size.  I will need to do some research to figure out what the
> > correct
> limit is.
> > It is going to be closer to 2^32 w/o adjusting for the abbreviated tag.
> >
> > [FP] Please elaborate on this. And you do mean CCM, right?
> 
> No, I actually meant GCM not CCM in this case because I have an idea of
> what the limit is due to the long discussions on the TLS mailing list.  I really
> have no idea at this time what the limit would be for CCM.  I need to re-read
> the documents and make some guesses.
> 
> Jim