Subject: [lp-wan] SCHC for CoAP OSCORE: Uncompressor protection

From: Christian Amsüss <[email-masked]>
Date: Tue, 21 Apr 2020 17:24:56 +0200

Hello Ana and Laurent,

(apologies for the remailing, this now has the correct WG address)

I've raised some concerns on whether the OSCORE properties of ensuring
that both parties agree on the intended meaning of a message. (Original
mail below, more on https://github.com/lp-wan/coap-compression/issues/9).

Have they been addressed in any way? The Point 3 slide of todays'
presentation seems not to have that in it. I had lost track of that
document and missed that it's already in IESG review, but view this as
an unresolved security convern.

There are two mitigation paths I see feasible:

* Put a Class-I option in the uncompression step that ccomprehensively
  describes the compression. It is never sent (unless in so-far
  hypothetical scenarios when Layer2-up-to-CoAP decompression is done on
  a different host than the end-to-end decription -- in which case it is
  direly needed anyway, see Point 2 of today's presentation), but is fed
  into the AAD to verify agreement.

* Alternatively (given the document is approaching its release -- this
  would not change anything in implementations), a rule would need to be
  added that for a single security context, the compression rules for
  the ciphertext need to be agreed on in advance and can not be changed.

  This would not wind up in the AAD, but it would be the responsibility
  of the key establishment procedure to ensure both parties agree on a
  compression (just as it is its responsibility that both parties agree
  on who they are).

  Putting a derivative of the compression rules in the info array of key
  derivation might be a good idea, but may or may not be necessary; it'd
  help to ask the OSCORE authors for opinions there.

I'm happy to participate in shaping these up, but right now I'm not sure
whether there isn't anything there yet anyway that I missed.

Kind regards
Christian

On Thu, Mar 28, 2019 at 12:28:23PM +0100, Christian Amsüss wrote:
> Hello Laurent,
> hello Göran,
> 
> Göran and I were just discussing general OSCORE things, and SCHC popped
> up. Now I haven't read the latest draft, but my understanding is that
> with OSCORE and SCHC, there's two compression steps taking place: One
> for the outer message, and one for the inner message.
> 
> The one for the outer message reaches into LoRA, and gets its static
> information from the lower layers.
> 
> But the OSCOER decompression does not necessarily need to happen at the
> same place (it should happen at the end point where security is
> terminated), which is reached over an Internet link. The Internet is a
> large place, and there's a danger of a static context to not be there,
> or be misconfigured.
> 
> If the recipient of the message decrypts it and decompresses the
> ciphertext, there is a danger of mixups to produce messages that were
> never intended to be sent but still appear authentic.
> 
> I could imagine that the first decompression step produces a field that
> indicates the context under which the inner message parts can be
> decompressed. That option would be our first example of a Class I
> option, as it's on the outside (so that it can be synthesized by the
> outer decompression), but needs to be part of the AAD so that decryption
> of the message reliably fails if there is disagreement over the context,
> or someone tampered with it.
> 
> 
> Hoping this is a useful comment, and happy to follow up on comments
> Best regards
> Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Laurent Toutain <[email-masked]>
Date: Fri, 24 Apr 2020 16:37:37 +0200

Hi Christian,

Thank you for your mail. Sorry to have missed it, that's an interesting
subject

If I understand well, you propose to include a hash of the inner header
into the AAD. "I" option is a good candidate for that.
I don't understand why it will improve security.

To be efficient, we need to have a malicious/bogus core SCHC sending packet
to the wrong destination,
This implies that if the wrong destination shares the same keys with the
good destination, the receiver cannot make the difference.  If the keys are
different
the packet the OSCORE message will be rejected. Does it reflect the
security consideration you raised?

Laurent

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 24 Apr 2020 17:17:40 +0200

Hello Laurent,

On Fri, Apr 24, 2020 at 04:37:37PM +0200, Laurent Toutain wrote:
> To be efficient, we need to have a malicious/bogus core SCHC sending
> packet to the wrong destination, This implies that if the wrong
> destination shares the same keys with the good destination, the
> receiver cannot make the difference.  If the keys are different the
> packet the OSCORE message will be rejected. Does it reflect the

This is not about a SCHC packet sent to the wrong destination, but at
the wrong time; the most compact example would be:

* Device sends a request whose compressed plaintext 0x01 means
  "fantastic".

* MITM delays the request.

* Administrator rolls out a new compression table where 0x00 means
  "enable" and 0x01 means "exterminate".

  All devices and the compression central agree that henceforth, only
  that compression shall be used.

* MITM injects the request. The server accepts it as valid and means to
  mean "exterminate". Robots take over the world.

Point is: OSCORE without special instructions does not impose an order
on messages, replay windows come in all shapes and sizes, and there is
nothing in SCHC that precludes changing the compression.

Kind regards
Christian

---

From: Laurent Toutain <[email-masked]>
Date: Tue, 28 Apr 2020 09:29:15 +0200

Hi Christian,

This is a good point, thanks for raising it. Yes, we can develop a way to
include a hash of the SCHC rules in the AAD, but I fear it is
a little bit too early to do it, we need to have at least a common
representation through the data model and I'm not sure it will be enough.
Developing an "I" option for that is also a very good idea, but out of the
scope of this document.

Maybe the best answer we can give at the moment is to mandate rekeying when
inner SCHC rules are changed? This blocks divergence
between the compressed content and the decompression rule.

Laurent