Subject: Re: [Ace] Security properties of CoAP message fields

From: Ludwig Seitz <[email-masked]>
Date: Thu, 1 Oct 2015 10:30:41 +0200

On 2015-10-01 05:11, Jim Schaad wrote:
> I want to go through the fields of a CoAP message and figure out what the
> security properties for each of the fields would need to be at a minimum.
> It would, of course, always be acceptable to provide a higher degree of
> security on any field, but knowing minimums helps.  I am not worried about
> how to achieve the required security level.  This should just be a
> discussion of what security levels are required.
[...]
  Code:  I think that this is going to depend on what the code is.  For 
C->RS
> messages and probably for RS->C success responses it should be integrity
> protected.  For RS->C failures, it would be good to be integrity protected.
> For Proxy->C responses it might not be able to be protected.  For Mallory->C
> responses it would never be protected.   Does C do different things if a
> protected message is sent and an unprotected message is returned?  (Assumes
> that C always initiates.)

In the case of CoAP observe or publish subscribe, can you always say 
that C initiates?
Sure at some point C sent the initial observe/subscribe message, but the 
subsequent updates/publications are actually initiated by the RS.

I guess when C initiates it should be possible for C to specify if it 
expects integrity protected response codes. This way a honest proxy can 
forward such a request to the RS (if it cannot provide the requested 
protection).

> Options:  Protection extended to options is going to be option and possibly
> dialog specific.
> *  None:  There are/may be options which are expected to be modified in
> transit.  There are options which may be/are expected to be inserted in
> transit.  These options cannot have any security protection on them
>
> *  Integrity Only:  The option can be visible to intervening entities, and
> indeed might be required to be visible for them to function properly, but
> there is a requirement that the option not be changed between the sender and
> the recipient.
>
> * Confidential (and integrity protected):  The option is not to be visible
> to intervening entities.

Note that the Proxy-Uri option is under some circumstances decomposed to 
the Uri-* options, thus it changes, but can be reconstructed and 
therefore integrity protected.
Perhaps some of the CoAP experts can confirm (or deny) this and add some 
explanatory example here?

/Ludwig
-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 01 Oct 2015 10:39:15 +0200

> security properties for each of the fields would need to be at a minimum.

That is not an easy undertaking...

E.g.:

> Message ID:  Should be integrity protected. 

There is probably no need to integrity-protect the message-ID.
The damage an attacker can do by spoofing the message ID is equivalent
to suppressing messages, and if an attacker can do the former they can
probably do the latter anyway.  (This is more at the level of protecting
connectivity.)

The beef is probably in the options.
See OSCOAP Appendix A for one such effort.

> * Confidential (and integrity protected):  The option is not to be visible

More precisely: visible only to specific entities (intervening or not).

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Thu, 1 Oct 2015 12:07:42 +0000

Hi Jim,

As Carsten pointed out, much of this is considered in Appendix A of
https://datatracker.ietf.org/doc/draft-selander-ace-object-security

(If anyone by chance gets motivated to actually read it, I would recommend
wait a little for version -03 for improved readability.)

Note that Appendix A applies to Mode:COAP which is the mode where payload,
selected headers and options are protected. There is also a Mode:PAYL
which is only protecting payload. Different Modes apply to different use
cases as is exemplified in section 2 and 3 of the draft (and below).

Comments inline:

On 2015-10-01 05:11, "Jim Schaad" <[email-masked]> wrote:

>I have provided first guesses at what security functions I think are
>needed,
>but am probably wrong about several of them.
>
>Part of the questions would be - if this changes in flight, should the
>receiver treat the message as invalid?
>
>Looking at a CoAP Message piece by piece I see the following:
>
>To and From Addressing:  Ok this is not really part of the message, I just
>want to ensure that nobody things that this should be protected in any way
>as it will be modified in transit by any number of CoAP and non CoAP
>entities.

We propose to integrity protect e.g. destination URI (the content of the
CoAP Options Uri-Host, Uri-Port, Uri-Path, Uri-Query) in the CoAP request.

>
>CoAP version number:  Maybe integrity protected - I don't see any benefit
>in
>hiding.

The mind set we have is that between any two endpoints with a security
association there may in general be some intermediate nodes. This means
that many of the header parameters doesn’t make sense to integrity
protect, because they are not preserved end-to-end.

For Version we were actually considering the benefits of having a proxy
translating between different versions, thus we omitted integrity
protection (which then needs to be considered with newer version of CoAP
appear so this does not introduce a vulnerability)

>
>Message type:  This might be interesting to integrity protect, I don't
>know
>there is any benefit in hiding.
>
>Token Length:  Implicitly protected if the token itself is protected.
>
>Token:  Should be integrity protected.  Protection should be extended to
>noting that a token does not exist.

None of these three necessarily survives a proxy.

>that C always initiates.)

The two Modes mentioned above address this differently.

For Mode:COAP a compliant node receiving a protected request must send a
protected response, and a compliant node receiving the response verifying
that it matches the request. In this case Code is integrity protected, so
this mode applies to the use cases where it is important to distinguish
e.g. GET from DELETE or where it is important that response codes are
integrity protected to ensure correct operations has been performed.

For Mode:PAYL only the payload is protected, so the change of Code should
not have a security implication. In this case there may be protected
message in only one direction, e.g. a GET response cached and forwarded to
different requesting clients.

>Message ID:  Should be integrity protected.

May be changed by intermediary.

>transit.  These options cannot have any security protection on them

We elaborate on this in Appendix A. One general indication are options
that are safe-to-forward may be integrity protected. But even if an option
is not safe-to-forward, the content of the option may be integrity
protected. The critical distinction seems to be if an option is changed in
a predictable way so it is possible to define an “invariant” which can be
integrity protected.

>the recipient

Yes, for each mode there are two cases.

>
>Body:  Depends on content.  Will either be integrity protected or
>confidential and integrity protected.

Agree

Göran

>
>Jim
>
>
>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 1 Oct 2015 21:17:45 -0700

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Thursday, October 01, 2015 5:08 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [Ace] Security properties of CoAP message fields
> 
> Hi Jim,
> 
> (If anyone by chance gets motivated to actually read it, I would recommend wait
> a little for version -03 for improved readability.)
> 
> selected headers and options are protected. There is also a Mode:PAYL which is
> only protecting payload. Different Modes apply to different use cases as is
> exemplified in section 2 and 3 of the draft (and below).
> 
> Comments inline:
> 
> >To and From Addressing:  Ok this is not really part of the message, I
> >just want to ensure that nobody things that this should be protected in
> >any way as it will be modified in transit by any number of CoAP and non
> >CoAP entities.
> 
> We propose to integrity protect e.g. destination URI (the content of the CoAP
> Options Uri-Host, Uri-Port, Uri-Path, Uri-Query) in the CoAP request.

But these are options, they are not what I would consider to be the to and from addressing.  This is what I would think of as the UDP addresses prepended to the front.  Sorry if I did not make that clearer.

> 
> >
> >CoAP version number:  Maybe integrity protected - I don't see any
> >benefit in hiding.
> 
> association there may in general be some intermediate nodes. This means that
> many of the header parameters doesn’t make sense to integrity protect,
> because they are not preserved end-to-end.
> 
> 
> translating between different versions, thus we omitted integrity protection
> (which then needs to be considered with newer version of CoAP appear so this
> does not introduce a vulnerability)

What would be the benefits of allow for a proxy to do version number changing.  That potentially says that the entire structure would be altered and the new things might need to be (or were) integrity protected.  This would start causing failures.

> >know there is any benefit in hiding.
> >
> >Token:  Should be integrity protected.  Protection should be extended
> >to noting that a token does not exist.
> 

What are the benefits of allowing a proxy to change the message type?  

Why would you have a situation where the proxy would change the token?  Why should this happen?  The entire value of the token is tied to the transaction that the client and the server are participating in.  Caching it would make no sense in many cases if the client uses a new token, because the proxy would not know that it would be in the same conversation.

> >messages and probably for RS->C success responses it should be
> >integrity protected.  For RS->C failures, it would be good to be
> >integrity protected.
> protected response, and a compliant node receiving the response verifying that
> it matches the request. In this case Code is integrity protected, so this mode
> applies to the use cases where it is important to distinguish e.g. GET from
> DELETE or where it is important that response codes are integrity protected to
> ensure correct operations has been performed.

So what would happen if a proxy returns an error code because it finds a problem of some type.  This would not be integrity protected.  Does the original message creator ignore that error because it is not integrity protected and resend the original request?  Would you end up with a case where the error is returned and is integrity protected, but not to the same context?  Does that make you accept or reject the message?

> 
> For Mode:PAYL only the payload is protected, so the change of Code should not
> have a security implication. In this case there may be protected message in only
> one direction, e.g. a GET response cached and forwarded to different requesting
> clients.

This basically falls into the world of - just protect the content.  That might also be a mixed message world where you combine the two different features with multiple security contexts.  (i.e. an encrypted message from a server (PAYL) and signed by the intermediate data server (COAP).

> May be changed by intermediary.

I can see this field as being changeable. So no protection makes sense

> 
> >
> >
> >Options:  Protection extended to options is going to be option and
> >possibly dialog specific.
> We elaborate on this in Appendix A. One general indication are options that are
> safe-to-forward may be integrity protected. But even if an option is not safe-to-
> forward, the content of the option may be integrity protected. The critical
> distinction seems to be if an option is changed in a predictable way so it is
> possible to define an “invariant” which can be integrity protected.

This method seems to be fraught with potential errors as new options are defined.  A non-critical option which is modified in a way not known to the recipient is going to cause failures without the ability to diagnose what is wrong.  Between not knowing which options might or might not be forwarded and which are modified vs which are protected seems to be a problem.

Jim

> 
> >
> >*  Integrity Only:  The option can be visible to intervening entities,
> >and indeed might be required to be visible for them to function
> >properly, but there is a requirement that the option not be changed
> >between the sender and the recipient
> >
> >* Confidential (and integrity protected):  The option is not to be
> >visible to intervening entities.
>

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 1 Oct 2015 21:22:22 -0700

> From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
> Sent: Thursday, October 01, 2015 1:31 AM
> To: [email-masked]

> > integrity protected.  For RS->C failures, it would be good to be
integrity
> protected.
> > protected message is sent and an unprotected message is returned?
> > (Assumes that C always initiates.)
> 
> In the case of CoAP observe or publish subscribe, can you always say that
C
> initiates?
expects
> integrity protected response codes. This way a honest proxy can forward
such a
> request to the RS (if it cannot provide the requested protection).

A couple of responses:

1) I was trying to simplify the world and made the assumption that the same
circumstances would come into effect when one reversed the roles.  Thus one
could swap C and RS without any changes in the analysis.

2)  This is one of the places where Figure 7 in the actors draft becomes
slightly confusing.  Who is client and who is RS in different types of
dialogs becomes weird.

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 02 Oct 2015 12:45:32 +0200

> What are the benefits of allowing a proxy to change the message type?  

For proxying between different transports such as UDP-to-TCP, this is a
valid use case.

> Why would you have a situation where the proxy would change the token?
> Why should this happen?  The entire value of the token is tied to the
> transaction that the client and the server are participating in.
> Caching it would make no sense in many cases if the client uses a new
> token, because the proxy would not know that it would be in the same
> conversation.

I guess this is also something related to the alternate transports use
case where the token might be used as a pointer to some internal state
within the proxy. (Not sure if that makes any sense, though.)

Grüße
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 02 Oct 2015 13:14:56 +0200

> transit.  These options cannot have any security protection on them

One interesting side note is that when a proxy inserts (or drops?)
options for some reason, the delta-encoded option number will change.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Fri, 2 Oct 2015 11:30:55 +0000

>within the proxy. (Not sure if that makes any sense, though.)

As far as I understand, there are basically no guarantees that a proxy is
not changing Type or Token, and therefore they cannot be integrity
protected between client and server.  I would also have liked an
end-to-end transaction identifier built into the CoAP message.

Göran

---

From: Göran Selander <[email-masked]>
Date: Fri, 2 Oct 2015 11:44:08 +0000

On 2015-10-02 13:14, "Olaf Bergmann" <[email-masked]> wrote:

>>possibly

We propose to integrity protect the delta-encoding of integrity protected
options present in the message. So unless one of those are dropped or
inserted this will not change. (And if one of those can be dropped or
inserted we can’t have that as integrity protected, so please let us know!)

Göran

---

From: Göran Selander <[email-masked]>
Date: Fri, 2 Oct 2015 13:37:48 +0000

Inline on the remaining comments.

On 2015-10-02 06:17, "Jim Schaad" <[email-masked]> wrote:

>>which is
>But these are options, they are not what I would consider to be the to
>and from addressing.  This is what I would think of as the UDP addresses
>prepended to the front.  Sorry if I did not make that clearer.

Sorry, I didn’t understand this reply: Do you see a problem with integrity
protecting these destination parameters

- Uri-Host = destination IP address

- Uri-Port = destination UDP port

>>that
>>protection
>What would be the benefits of allow for a proxy to do version number
>changing.  That potentially says that the entire structure would be
>altered and the new things might need to be (or were) integrity
>protected.  This would start causing failures.

We have reconsidered this and agree that version number had better be
integrity protected. Will be changed in -03.

>So what would happen if a proxy returns an error code because it finds a
>problem of some type.  This would not be integrity protected.  Does the
>original message creator ignore that error because it is not integrity
>protected and resend the original request?  Would you end up with a case
>where the error is returned and is integrity protected, but not to the
>same context?  Does that make you accept or reject the message?

Good question. This boils down to what you expect a proxy should be able
to do and how much you trust it.

If there is no security association with the proxy it is not possible to
verify these error messages. One option is to ignore them and retransmit
request until timeout. This may be the right behaviour e.g. to meet an
attempt to DoS the client sending fake error codes. Alternatively or in
addition the application may analyse error code before or after timeout
and attempt workaround (taking into account that the information may be
wrong). This would require that the client caches a message even if it is
not a verified response to the request.

If there is a security association with the proxy, then there are various
different scenarios for how to gain trustworthy information about the
capabilities/status etc. of the proxy, or other reason for the proxy not
performing the requested function. I don’t know if the proxy protecting
the error message is a good way, since that would require the client to
accept more than one response context for a given request.

So I’m not sure what is the best processing recommendations here, or if it
should be left to implementation (with a security consideration explaining
the issue). Generally speaking, I think having client-server integrity of
the code is an important feature and I would trade that against timely
proxy operations.

>This basically falls into the world of - just protect the content.

Yes.

> That might also be a mixed message world where you combine the two
>different features with multiple security contexts.  (i.e. an encrypted
>message from a server (PAYL) and signed by the intermediate data server
>(COAP).

Yes, the modes can be combined like that. In this case, there would be
both an object security Option and the Content-Format
indicating that the payload is a protected object.

>>that are
>This method seems to be fraught with potential errors as new options are
>defined.  A non-critical option which is modified in a way not known to
>the recipient is going to cause failures without the ability to diagnose
>what is wrong.  Between not knowing which options might or might not be
>forwarded and which are modified vs which are protected seems to be a
>problem.

I would like to understand your concern better, could you please make an
example and indicate if the option is Safe-to-Forward or not, and which
parties supports the option and which not.

Göran

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Oct 2015 08:39:24 -0700

> From: Olaf Bergmann [mailto:[email-masked]]
> Sent: Friday, October 02, 2015 3:46 AM
> To: Jim Schaad <[email-masked]>
> Cc: 'Göran Selander' <[email-masked]>; [email-masked]
> For proxying between different transports such as UDP-to-TCP, this is a valid use
> case.

Are there examples in a document that describe this?

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Oct 2015 08:41:29 -0700

> Sent: Friday, October 02, 2015 4:15 AM
> Cc: [email-masked]
> > *  None:  There are/may be options which are expected to be modified
> > in transit.  There are options which may be/are expected to be
> > inserted in transit.  These options cannot have any security
> > protection on them
> 
> One interesting side note is that when a proxy inserts (or drops?) options for
> some reason, the delta-encoded option number will change.

I don't think this is a big deal as we can use the absolute option number in constructing the authentication string.

Jim

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Oct 2015 08:49:12 -0700

> Sent: Friday, October 02, 2015 6:38 AM
> >> >To and From Addressing:  Ok this is not really part of the message,
> >> >I just want to ensure that nobody things that this should be
> >> >protected in any way as it will be modified in transit by any number
> >> >of CoAP and non CoAP entities.
> >>
> >> We propose to integrity protect e.g. destination URI (the content of
> >>the CoAP  Options Uri-Host, Uri-Port, Uri-Path, Uri-Query) in the CoAP
> >>request.
> >
> >and from addressing.  This is what I would think of as the UDP
> >addresses prepended to the front.  Sorry if I did not make that clearer.
> 

I was looking at the address headers in a UDP message or TCP message.  What you are describing are options.  Options are protected as if they are options not as if they are an IP address placed on the front of a packet which gets changed as it progresses through various routers.  These are not properly part of a CoAP message.

If you are familiar with email - think of the difference between a To header in an SMTP header, and the RCPT SMTP command.  The first can be authenticated, but does not necessarily have anything to do with the RCPT address (think BCC).

> >> For Mode:COAP a compliant node receiving a protected request must
> >>send a  protected response, and a compliant node receiving the
> >>response verifying that  it matches the request. In this case Code is
> >>integrity protected, so this mode  applies to the use cases where it
> >>is important to distinguish e.g. GET from  DELETE or where it is
> >>important that response codes are integrity protected to  ensure
> >>correct operations has been performed.
> >
> >So what would happen if a proxy returns an error code because it finds
> >a problem of some type.  This would not be integrity protected.  Does
> >the original message creator ignore that error because it is not
> >integrity protected and resend the original request?  Would you end up
> >with a case where the error is returned and is integrity protected, but
> >not to the same context?  Does that make you accept or reject the message?
> 
> Good question. This boils down to what you expect a proxy should be able to do
> and how much you trust it.
> 
> If there is no security association with the proxy it is not possible to verify these
> error messages. One option is to ignore them and retransmit request until
> timeout. This may be the right behaviour e.g. to meet an attempt to DoS the
> client sending fake error codes. Alternatively or in addition the application may
> analyse error code before or after timeout and attempt workaround (taking into
> account that the information may be wrong). This would require that the client
> caches a message even if it is not a verified response to the request.
> 
> If there is a security association with the proxy, then there are various different
> scenarios for how to gain trustworthy information about the capabilities/status
> etc. of the proxy, or other reason for the proxy not performing the requested
> function. I don’t know if the proxy protecting the error message is a good way,
> since that would require the client to accept more than one response context
> for a given request.
> 
> should be left to implementation (with a security consideration explaining the
> issue). Generally speaking, I think having client-server integrity of the code is an
> important feature and I would trade that against timely proxy operations.
> 
> 

Agreed.  This is hard.  It needs to be considered, discussed and written down.

> >> We elaborate on this in Appendix A. One general indication are
> >>options that are  safe-to-forward may be integrity protected. But even
> >>if an option is not safe-to-  forward, the content of the option may
> >>be integrity protected. The critical  distinction seems to be if an
> >>option is changed in a predictable way so it is  possible to define an
> >>“invariant” which can be integrity protected.
> >
> >This method seems to be fraught with potential errors as new options
> >are defined.  A non-critical option which is modified in a way not
> >known to the recipient is going to cause failures without the ability
> >to diagnose what is wrong.  Between not knowing which options might or
> >might not be forwarded and which are modified vs which are protected
> >seems to be a problem.
> 
> example and indicate if the option is Safe-to-Forward or not, and which parties
> supports the option and which not.

This may take a while as I am going to need to understand the CoAP options much better to give a concrete example.  I am currently thinking in the world of possibilities not the real world.

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 02 Oct 2015 17:52:18 +0200

> Are there examples in a document that describe this?

Not really examples. There is an ongoing discussion about [0] where
Section 4 proposes two alternative formats for the CoAP base header that
must use NON as the message type (hence removing retransmissions and
ACKs that are not necessary for reliable transport). The third
alternative presented there even removes the message type from the
(CoAP/TCP) base header entirely. (There has been a lengthy discussion
about eliding CON+ACK from CoAP+TCP but I am not sure if that has lead
to a final conclusion by now.)

[0] https://tools.ietf.org/html/draft-tschofenig-core-coap-tcp-tls

Grüße
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Fri, 02 Oct 2015 17:53:49 +0200

"Jim Schaad" <[email-masked]> writes:

>> options for
> I don't think this is a big deal as we can use the absolute option
> number in constructing the authentication string.

Yes, meaning that it must be constructed before message
serialization. Hm....

Grüße
Olaf

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 2 Oct 2015 11:48:54 -0700

> Sent: Friday, October 02, 2015 8:52 AM
> >> For proxying between different transports such as UDP-to-TCP, this is
> >> a valid use case.
> >
> Not really examples. There is an ongoing discussion about [0] where Section 4
> proposes two alternative formats for the CoAP base header that must use NON
> as the message type (hence removing retransmissions and ACKs that are not
> necessary for reliable transport). The third alternative presented there even
> removes the message type from the
> (CoAP/TCP) base header entirely. (There has been a lengthy discussion about
> eliding CON+ACK from CoAP+TCP but I am not sure if that has lead to a final
> conclusion by now.)

I can understand why this would not have the same requirements for the non-secure case.  It may be that this needs to be altered for the secure case depending on what the properties that are trying to be obtained.  The CoAP->TCP proxy can do the confirm messages back in the insecure case.  This may not be true in the secure case.

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Sat, 03 Oct 2015 11:57:38 +0200

On October 2, 2015 8:48:54 PM GMT+02:00, Jim Schaad <[email-masked]> wrote:

>> eliding CON+ACK from CoAP+TCP
[...]
>
>I can understand why this would not have the same requirements for the
>non-secure case.  It may be that this needs to be altered for the
>secure case depending on what the properties that are trying to be
>obtained.  The CoAP->TCP proxy can do the confirm messages back in the
>insecure case.  This may not be true in the secure case.

Okay, so as a take-away message I get that we (= the core wg) should take into consideration that altering this will also have negative effect on the security level that can be achieved when CoAP+TCP proxies are in the communication path.

Grüße
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 3 Oct 2015 13:52:05 +0200

The message type only has a hop-by-hop meaning, so I’m not sure what we are protecting here.
A CoAP+TCP proxy cannot be worse in any way from any other kind of proxy.
(To give another example for how message types are not end-to-end, what may be a separate response on one side of a proxy may be piggybacked on an ACK on the other side.)

Grüße, Carsten

On 3 October 2015 at 11:58:01, Olaf Bergmann ([email-masked]) wrote:

On October 2, 2015 8:48:54 PM GMT+02:00, Jim Schaad <[email-masked]> wrote:  

[...]  

Grüße  
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 5 Oct 2015 09:12:39 +0200

> Yes, meaning that it must be constructed before message

In draft-selander-ace-object-security we suggested that you create a 
separate list of integrity protected options (using the delta-encoding) 
as input for signing/MACing.

We considered and rejected the idea of using the actual option numbers 
instead, because you then need an additional piece of parsing code in 
your library, whereas with the delta encoding you can reuse the CoAP code.

Either way, you need additional memory to create the separate list of 
options that is going to be integrity protected.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 05 Oct 2015 09:38:18 +0200

Ludwig Seitz <[email-masked]> writes:

> separate list of integrity protected options (using the
> delta-encoding) as input for signing/MACing.
>

I do not see why you need an additional piece of parsing code?

But I agree that there will be many cases where using the deltas can be
more efficient, especially when you have only a small number of
non-protected options.

Yes.

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 5 Oct 2015 11:17:45 +0200

> I do not see why you need an additional piece of parsing code?

Well some code has to create the data object (including the option 
numbers) that you are going to sign/MAC.

Without the delta-encoding this has to be some new code (at least 
partially).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 05 Oct 2015 11:35:29 +0200

> Without the delta-encoding this has to be some new code (at least

Call me dumb, but I do not see a big difference between the two
cases. With the delta-encoding you may have to prepare input data for
your MAC function, with real option numbers you must prepare input data
for your MAC function. (If you use real option numbers the spec will
have to say something about the canonicalization which comes for free
when you use the already encoded options, though.)

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 5 Oct 2015 12:33:11 +0200

> when you use the already encoded options, though.)

You are right, the difference is indeed small, but when you use the 
delta-encoding you can reuse CoAP code without any modification, whereas 
when you want to use the real numbers you have to rewrite some parts of 
that.

Anyways my point was just to express a slight preference for generating 
the input for the MAC/signature functions as a delta encoded list of 
options.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 05 Oct 2015 13:00:17 +0200

Ludwig Seitz <[email-masked]> writes:

> delta-encoding you can reuse CoAP code without any modification,
> whereas when you want to use the real numbers you have to rewrite some
> parts of that.
>
> Anyways my point was just to express a slight preference for
> generating the input for the MAC/signature functions as a delta
> encoded list of options.

Okay, thanks for the clarification. As you may have inferred from my
posts, I have no strong opinion on either of them. I can imagine that
using delta-encoded can have some benefit in certain scenarios.

Grüße
Olaf