Subject: [core] 🔔 WG Call for Adoption on draft-amsuess-core-repeat-request-tag-00

From: Jaime Jiménez <[email-masked]>
Date: Wed, 4 Oct 2017 08:00:29 +0000

Dear CoRE WG,

during last IETF the following draft was presented:
https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00 <https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00> 

The draft mitigates known issues with the freshness of a CoAP request as well as fragmentation of the CoAP message body. 
There was strong room consensus or adoption so this is just to confirm it. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment.

Target for the end of the WGA call is 16th October. 

Ciao,
- - Jaime Jiménez

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 4 Oct 2017 13:11:14 +0200

On 2017-10-04 10:00, Jaime Jiménez wrote:
> https://tools.ietf.org/html/draft-amsuess-core-repeat-request-tag-00
> 
> The draft mitigates known issues with the freshness of a CoAP request as 
> well as fragmentation of the CoAP message body.
> There was strong room consensus or adoption so this is just to confirm 
> it. Please reply to the list with your comments, including although 
> not limited to whether or not you support adoption. Non-authors are 
> especially encouraged to comment.
> 

I support adoption of this draft.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 4 Oct 2017 16:50:47 +0200

Two comments:

IMHO the presented problems are not worthwhile to solve. Additionally, I
would prefer if the CORE working group finishes already chartered items
rather than always adding new stuff.

On 10/04/2017 10:00 AM, Jaime Jiménez wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 5 Oct 2017 07:35:39 +0000

Hi Hannes,

This draft contains two security updates to CoAP, so this is “fixing
stuff" rather than "adding new stuff". Just as an example, people
deploying CoAP (with e.g. DTLS) in actuator applications may be unaware
that they are vulnerable to request delay attacks:

https://tools.ietf.org/html/draft-mattsson-core-coap-actuators-02#section-2
.2

Why isn’t this worthwhile to solve?

Göran

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 5 Oct 2017 11:50:26 +0000

As expressed at the IETF99 meeting, I support WG adoption of this draft.

Thanks,
Francesca

From: core [mailto:[email-masked]] On Behalf Of Jaime Jiménez
Sent: den 4 oktober 2017 10:00
To: [email-masked] WG ([email-masked]) <[email-masked]>
Subject: [core] 🔔 WG Call for Adoption on draft-amsuess-core-repeat-request-tag-00

Dear CoRE WG,

Ciao,
- - Jaime Jiménez

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 6 Oct 2017 20:47:52 +0200

I support WG adoption of this draft.

Best,
/Marco

On 2017-10-04 10:00, Jaime Jiménez wrote:
> The draft mitigates known issues with the freshness of a CoAP request
> as well as fragmentation of the CoAP message body. 

-- 
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: +46 (0)70 60 46 501
https://www.sics.se
https://www.sics.se/~marco/

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 Oct 2017 08:53:23 +0200

Hi Hannes,

On Oct 4, 2017, at 16:50, Hannes Tschofenig <[email-masked]> wrote:
> 
> Two comments:
> 
> IMHO the presented problems are not worthwhile to solve.

I’m not sure I understand.  The problem pointed out is a security problem in certain applications.
Are you saying we shouldn’t invest time in these applications?
Or are you saying this should instead be solved within the application (which is perfectly possible, but not something we can expect developers to always get right)?

> Additionally, I

I think we can agree on this, but addressing a security problem does have a special importance.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Wed, 25 Oct 2017 13:04:12 -0700

I should have relied at the time, but better late than never.

I believe that the request field absolute must be adopted.  I am agnostic about the repeat field although I do see the usefulness of having it

Jim

From: core [mailto:[email-masked]] On Behalf Of Jaime Jiménez
Sent: Wednesday, October 4, 2017 1:00 AM
To: [email-masked] WG ([email-masked]) <[email-masked]>
Subject: [core] 🔔 WG Call for Adoption on draft-amsuess-core-repeat-request-tag-00

Dear CoRE WG,

Ciao,

- - Jaime Jiménez

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 26 Oct 2017 09:58:21 +0200

My take on this is that the Repeat option seems quite useful for replay mitigation in the case where OSCORE server reboots. Thus, I support the adoption.

Mališa

> On 25 Oct 2017, at 22:04, Jim Schaad <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Oct 2017 12:57:34 +0200

Hi Carsten,

I fail to understand the reasoning.

You want end-to-end security but then you put a proxy in the middle.
Architecturally not a great idea since you don't have to do that.

Now the proxy is there. You seem to trust the proxy to process and relay
your messages. Probably the proxy does much in order to justify the
existence.

But then the proxy you previously trusted becomes evil and mounts
attacks against your communication.

Then, you add this extension.

However, you nicely trust the proxy not to do all sorts of other things.
For example, it could just drop your messages. It could also delay your
messages (which would have pretty nasty effects in an industrial IoT
environment where timing matters). Then, you also expose lots of
meta-data to this proxy as well (leading to privacy violations). That's
seems just fine (and maybe be covered as part of a later draft).

For this reason I believe the story is constructed.

If you believe the feature is essential for OSCOAP, as it sounds from
your second response, then why is this not part of OSCOAP (which is also
still work in progress)?

Ciao
Hannes

---

From: Joakim Brorsson <[email-masked]>
Date: Thu, 26 Oct 2017 13:24:26 +0200

Hello Hannes.

The situation is in my opinion much more nuanced. Trust is not all or
nothing.

We might want to trust a proxy with availability, in order to obtain
asynchronicity. But we can not trust the proxy with actual plaintext data,
since the data owner and the infrastructure owner might not be the same
person.

Without separating the concepts of confidentiality, integrity and
availability, we become very limited in how we can design secure systems.

Regards
Joakim

2017-10-26 12:57 GMT+02:00 Hannes Tschofenig <[email-masked]>:

> > Or are you saying this should instead be solved within the application
> (which is perfectly possible, but not something we can expect developers to
> always get right)?
> >
> >> Additionally, I

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Oct 2017 13:41:51 +0200

Hi Joakim,

I fully understand that trust is not black and white.

When I read a document I have to figure out whether this is something we
at ARM also encounter in our deployments. I am also happy to learn when
other companies encounter deployment challenges and share them
(including solutions) with the rest of the community.

Here, it appears, that the requirements just fall out of the blue sky.

If you, Carsten, Jim, and Malisa have IoT deployments that need this
then you should say "yes, we need this for our deployment". This is the
purpose of the call for adoption.

Ciao
Hannes

On 10/26/2017 01:24 PM, Joakim Brorsson wrote:
> asynchronicity. But we can not trust the proxy with actual plaintext
> data, since the data owner and the infrastructure owner might not be the
> same person.
> 
> 2017-10-26 12:57 GMT+02:00 Hannes Tschofenig <[email-masked]
> <mailto:[email-masked]>>:
> 
>     Hi Carsten,
> 
>     > On Oct 4, 2017, at 16:50, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Two comments:
>     >>
>     > Or are you saying this should instead be solved within the
>     application (which is perfectly possible, but not something we can
>     expect developers to always get right)?
>     >
>     >> Additionally, I
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/core>
> 
>

---

From: Göran Selander <[email-masked]>
Date: Thu, 26 Oct 2017 12:43:25 +0000

Hi Hannes, 

There appears to be profound confusion about what this draft is about, so
it is even hard to map the statements made in your mail to the draft.

The problem statements leading up to this draft are addressing issues with
CoAP even when a security protocol such as DTLS is used. The attacks can
be carried out by on-path attackers and thus does not require a proxy.

The draft contains security updates. Security updates in general are of
the nature that you make them when you realise that there is a potential
issue, even if you have not experienced an attack. If ARM is only making
security updates after an attack is a fact I think many people would not
dare to use ARM based devices.

Please be specific with your concerns by referencing the attacks which are
protected against rather than make sweeping arguments.

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Oct 2017 14:58:12 +0200

Hi Hannes,

the freshness vulnerability addressed here indeed occurs with proxies.
But it also occurs with anything else that can hold back and replay traffic, including routers and even possibly an unrelated wireless node that manages to jam the forwarding to the receiving node while making a copy of the original transmission.  Decryption capability is not required for this to work.  This is a bit like some of the well-known key fob vulnerabilities.

It is possible to address this at the application level (Web applications typically do), and for a while I thought that  would be going to be all we need.
As far as I understand, the argument is that defining a standard CoAP option for this reduces the variability and makes it more likely that the mechanism actually will work right, more independent of the security acuity of the application developer.  That is typically an argument to which the IETF is quite accessible.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Oct 2017 21:26:35 +0200

Hi Carsten,

we are not deploying gateways in the way that they would need this
functionality. I believe that should be OK.

>From the way you phrase it below it sounds like you should include the
functionality in the OSCOAP spec.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Oct 2017 21:40:08 +0200

> functionality. I believe that should be OK.

No routers, no unrelated wireless nodes either?
I’m not sure we are communicating.

> functionality in the OSCOAP spec.

I don’t think information that is needed to secure a pure-DTLS implementation should be hidden in the OSCORE spec.

Grüße, Carsten

---

From: Jaime Jiménez <[email-masked]>
Date: Sat, 28 Oct 2017 08:11:02 +0000

Dear CoRE WG,

I have extended few more days the call for adoption of this draft as there was a lively discussion around it.
I believe that at this point the group has expressed rough consensus for the adoption of this draft.

We ask the authors to please send a new version under draft-ietf-core as soon as possible. The draft can also be set under CoRE’s repository -like the rest of the drafts- if so they want.

Ciao,
- - Jaime Jiménez