Subject: [core] Agenda

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Mar 2016 17:45:03 +0100

Hi all,

I thought I should kick of a discussion about the agenda items for the
upcoming IETF meeting. Too early to have that discussion? I don't think
so given that the meeting is roughly in a week.

I would like to see the following items discussed:

 1) Resource Directory
 2) CORE Interfaces
 3) Block Transfer
 4) CoAP over TCP
 5) CoAP/HTTP Mapping
 6) Representing CoRE Formats in JSON and CBOR

Let us try to finish some stuff.

For that reason I don't want to see anything else on that agenda.

Ciao
Hannes

---

From: Alexander Pelov <[email-masked]>
Date: Fri, 25 Mar 2016 18:33:29 +0100

Dear Hannes,

Thanks for starting the discussion on the ML.

To your list of items I would add the following topic:
*) CoOL protocol for constrained device management

In view of the 4 drafts and the management tool that have been released two weeks ago. 
https://datatracker.ietf.org/doc/draft-turner-core-cool-problem-statement/ <https://datatracker.ietf.org/doc/draft-turner-core-cool-problem-statement/>
https://datatracker.ietf.org/doc/draft-somaraju-core-sid/ <https://datatracker.ietf.org/doc/draft-somaraju-core-sid/> 
https://datatracker.ietf.org/doc/draft-veillette-core-yang-cbor-mapping/ <https://datatracker.ietf.org/doc/draft-veillette-core-yang-cbor-mapping/> 
https://datatracker.ietf.org/doc/draft-veillette-core-cool/ <https://datatracker.ietf.org/doc/draft-veillette-core-cool/>
https://github.com/lemikev/pyang/blob/master/pyang/plugins/sid.py <https://github.com/lemikev/pyang/blob/master/pyang/plugins/sid.py>

I share without reserves your will to get the work done and I am very happy to be on the same page with you on this. Let’s keep it lean and get to the running code.

Best,
Alexander

> Le 25 mars 2016 à 17:45, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Hi all,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Mar 2016 11:45:58 +0000

Hi,

> On 25 Mar 2016, at 16:45, Hannes Tschofenig <[email-masked]> wrote:
> 

As your WG future responsible Area Director: +100.

---

From: peter van der Stok <[email-masked]>
Date: Sat, 26 Mar 2016 12:48:22 +0100

Hi Hannes,

I do sympathize with your wish to get stuff finished.
I also understand your choice.
However, it is more than getting things on the agenda and nothing but 
that.

What are the goals:
Do you want all development on the drafts stopped, WGLC called and only 
big mistakes removed and phrases improved?
Or just consensus on the end goals of the documents, and authors decide 
what comments are in scope?
Or just a time of 1 month after which the drafts are finished, full 
stop?
Or .....

Can you elaborate a bit?

Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Mar 2016 13:26:41 +0000

Peter,

Just to comment about what is on the agenda versa what is being worked on: not having a document on agenda of s face-to-face meeting doesn't mean that all work need to stop on such document.

Chairs should reply to the rest of your questions.

> On 26 Mar 2016, at 11:48, peter van der Stok <[email-masked]> wrote:
> 
> Hi Hannes,
> 
> However, it is more than getting things on the agenda and nothing but that.
> 
> What are the goals:
> Do you want all development on the drafts stopped, WGLC called and only big mistakes removed and phrases improved?
> Or just consensus on the end goals of the documents, and authors decide what comments are in scope?
> Or just a time of 1 month after which the drafts are finished, full stop?
> Or .....
> 
> Can you elaborate a bit?
> 
> Peter
>

---

From: peter van der Stok <[email-masked]>
Date: Sat, 26 Mar 2016 14:39:56 +0100

Hi Alexey,

few words inline

Alexey Melnikov schreef op 2016-03-26 14:26:
> Peter,
> 
> Just to comment about what is on the agenda versa what is being worked
> on: not having a document on agenda of s face-to-face meeting doesn't
> mean that all work need to stop on such document.

We fully agree. no discussion.
> Chairs should reply to the rest of your questions.

My question was to Hannes how he thinks we should try to get movement in 
the proposed drafts.
According to me each draft has a different history with changes.
My suggestions are meant to start the discussion.
May be we can come to a set of topics to be filled in by each author to 
define a horizon (content-wise or time-wise) for each draft.

Peter
>> Do you want all development on the drafts stopped, WGLC called and 
>> only big mistakes removed and phrases improved?

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 26 Mar 2016 14:51:31 +0100

Hi Peter,

I am happy to share my thoughts with you and the group.

There is this unfortunate 80:20 rule and we are suffering badly from it
in the working group. Whenever a new topic is presented in the group
everyone raises their hands and wants to work on it. Unfortunately, the
energy vanishes after 80% of the work is done and then there is no
progress anymore. Most (if not all) of those who were previously
interested moved on to other topics and rather want to discuss their
latest document.

This is, however, not the way to get things done. As with all working
groups new work gets added only when old work gets finished (or killed).
Many of the currently chartered items have been there for a very, very
long time. They need more attention!

Note that I am by no way saying that new work has to be stopped or
delayed. As Alexey mentioned everyone should feel free to work on their
favorite items as much as they like. Using the official face-to-face WG
meeting for discussing non-WG items is IMHO the wrong approach to make
progress.

You are also co-author of one of the WG items, namely the Resource
Directory. This work has (according to the tracker) been started early
2011 and is still in the status of a WG draft. People are implementing
it and shipping products based on the draft. Other organizations use it
in their architecture and have been asking for a long time already when
it gets finished. What should I tell them?* Why has it taken so long? It
is not even clear to me what has to be done to finish it. I have seen a
minor draft update prior to the submission deadline but I have seen no
mail explaining why changes have been made nor any discussions leading
to those changes. From a transparency and accountability point of view
document authors & editors should tell the group what the open issues
are, what needs to be done to close them.

Ciao
Hannes

*: In a recent mail I made the observation that the milestones are
completely out of date and do not help anyone to guess the targeted
completion date.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Mar 2016 16:22:42 +0100

Hi Hannes,

thanks for volunteering as the new WG secretary.

I have put up the current status with respect to slot requests at

https://github.com/core-wg/ietf95/wiki

This is a wiki, so I'm asking the discussion leaders for the slots to
update the information right there.

We need to get more detailed objectives for the items; it is not
sufficient to have an item on the agenda, we also need to know what
needs to be decided.

Any slot request that is missing?

Any other input on time needed, priorities?

Andrew and I have to put in a revised agenda by Monday, so items where
do don't have a discussion leader and detailed objectives are a bit
endangered.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 26 Mar 2016 17:05:07 +0100

Hi Carsten,

thanks for putting up a Wiki.

For the Block Transfer draft it is obviously difficult to predict what
the IESG comments will be; hence a short slot is appropriate.

For many of the other WG items (e.g., CoRE Resource Directory,
draft-ietf-core-interfaces, draft-ietf-core-http-mapping,
draft-ietf-core-links-json-04) it is not clear what the open issues are
since the document authors do not seem to either use the WG issue
tracker or haven't touched it for a while.

Could this be done before the meeting starts? This would allow folks to
prepare for the discussion. I would like to avoid being in a meeting
where nobody knows what is being decided.

draft-ietf-core-links-json-04 does not seem to be listed as a separate
item on the agenda?

Do we know who is going to attend the meeting to assign presenters to
the individual items?

Ciao
Hannes

PS: Btw, I am not volunteering to be the WG secretary. The group has two
chairs and you guys should be able to handle this task easily.

PPS: I still believe that SENML, COOL/COMI, and the security discussion
requires too much preparation for the group upfront so that it will
actually distract everyone.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Mar 2016 17:21:28 +0100

> the IESG comments will be; hence a short slot is appropriate.

Exactly.
The one issue that has taken a while to resolve at the end was the
interaction with Object Security, we can discuss that part there, and
Göran has volunteered to lead that discussion.

> where nobody knows what is being decided.

Yes, that would indeed be useful.

> draft-ietf-core-links-json-04 does not seem to be listed as a separate

I have lumped it under resource-directory because I am not aware of
anything to decide on this document per se, but the interaction with RD
is the interesting one.  Same with fetch/patch.

> Do we know who is going to attend the meeting to assign presenters to

While there seems to be some subsetting here, we probably will have a
quorum.  Discussion leaders: Please note down yourself on the Wiki...

> actually distract everyone.

Those are areas where a lot of preparation has already happened.

(The agenda has 60 minutes more of material right now than we have time;
we might indeed want to minimize the discussion on SenML, and the Friday
items are the compressible ones if we need more time for the Tuesday ones.)

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sat, 26 Mar 2016 21:24:26 +0000

Hi Hannes,

>For many of the other WG items (e.g., CoRE Resource Directory, draft-ietf-core-interfaces, draft-ietf-core-http-mapping,
>draft-ietf-core-links-json-04) it is not clear what the open issues are since the document authors do not seem to either use the WG issue tracker or haven't touched it for a while.

Here is a summary of the status for draft-ietf-core-http-mapping:

1) From IETF-94 (Yokohama) minutes

https://www.ietf.org/proceedings/94/minutes/minutes-94-core

"A post WGLC check on draft-ietf-core-http-mapping-07 revealed remaining outstanding comments."

2) Here is our recent Email to the list to close these remaining outstanding comments (from Klaus)

https://www.ietf.org/mail-archive/web/core/current/msg06866.html

3) Here is our update of the draft (to -08) that incorporates nearly all the comments:

https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#appendix-A

  "Changes from ietf-07 to ietf-08:

  o  Addressed WGLC review comments from Klaus Hartke as per the
     correspondence of March 9, 2016 on the CORE WG mailing list."

>Do we know who is going to attend the meeting to assign presenters to the individual items?

>From the Wiki that Carsten just made

"•HTTP Mapping (15) Thomas Fossati (Akbar is the backup)

draft-ietf-core-http-mapping-08 2016-03-19

Objective: Review updates to address the WGLC comments from Klaus Hartke"

> I would like to avoid being in a meeting where nobody knows what is being decided.

Yes, I agree.  Do the above clarify the points for draft-ietf-core-http-mapping?  Please tell us if you need any more information from the authors.

Best Regards,

Akbar

-----Original Message-----
From: core [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Saturday, March 26, 2016 12:05 PM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [core] Agenda

Hi Carsten,

For the Block Transfer draft it is obviously difficult to predict what the IESG comments will be; hence a short slot is appropriate.

For many of the other WG items (e.g., CoRE Resource Directory, draft-ietf-core-interfaces, draft-ietf-core-http-mapping,
draft-ietf-core-links-json-04) it is not clear what the open issues are since the document authors do not seem to either use the WG issue tracker or haven't touched it for a while.

Could this be done before the meeting starts? This would allow folks to prepare for the discussion. I would like to avoid being in a meeting where nobody knows what is being decided.

draft-ietf-core-links-json-04 does not seem to be listed as a separate item on the agenda?

Do we know who is going to attend the meeting to assign presenters to the individual items?

Ciao
Hannes

PS: Btw, I am not volunteering to be the WG secretary. The group has two chairs and you guys should be able to handle this task easily.

PPS: I still believe that SENML, COOL/COMI, and the security discussion requires too much preparation for the group upfront so that it will actually distract everyone.

On 03/26/2016 04:22 PM, Carsten Bormann wrote:
>> I thought I should kick of a discussion about the agenda items for
>> the upcoming IETF meeting. Too early to have that discussion? I don't
>> think so given that the meeting is roughly in a week.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Mar 2016 00:08:32 +0100

Hi Akbar,

thanks for the quick feedback and for the details.

I took a look at the mailing list and noticed that the draft has gotten
very little feedback during the WGLC. Given the number of people who had
provided reviews earlier during the process (as captured in the
acknowledgement section) one would hope that those folks could also
briefly look at the document and say something (even if it is only a 'I
have read it and it looks good.' comment.)

Klaus provided an extensive review for which received a detailed answer
(around 6 months later). What I haven't seen is a confirmation from
Klaus saying that he is happy with the way how the authors/editors
handled his review. Basically, there was no discussion about the issues
raised on the list. His review lead to a number of changes throughout
the document, as it can easily be seen from the diff.

Kepeng provided feedback saying that the document should be experimental
but I didn't see a response (and the document is still informational).

I asked a question about the mapping of HTTP parameters to CoAP options
is. The conclusion was that there is no one-to-one mapping since there
is no feature parity. As such, there is probably some text in the
document that describes the limitations. (I haven't checked it yet.)

I believe the HTTP-CoAP mapping document shows that any type of gateway
is somewhat complex even for something as simple as a mapping from CoAP
to HTTP (and vice versa). I suspect you guys have worked on an
implementation to get all the details into the document.

From your judgement do you believe there are no further open issues with
the document or do you see any concerns with the small number of WGLC
reviews? Did you reach out to some other implementers to get their input?

Ciao
Hannes

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 27 Mar 2016 03:35:24 +0000

Hi Hannes,

>Klaus provided an extensive review for which received a detailed answer (around 6 months later).

Yes, the delay was exceptionally long because as we indicated in our email:

".. apologies for the long delay in answering your comments.   None of the authors were able to make it to last November's IETF meeting where we had wanted to speak to you directly to resolve some of the issues.  This resulted in an overall delay to the entire process.  However, we were recently able to coordinate a point by point response to comments.  Please review and tell if us you agree with the responses..."

>What I haven't seen is a confirmation from Klaus saying that he is happy with the way how the authors/editors handled his review. Basically, there was no discussion about the issues raised on the list. His review lead to a number of changes throughout the document, as it can easily be seen from the diff.

Yes, so we decided to incorporate the comments directly into the draft and allow everyone in the WG to see the changes as parsing all the impacts from Email discussion is difficult.  Our major hope is that we can have a good review and discussion in Buenos Aires and get Klaus and hopefully the rest of the WG to agree (or disagree) with the changes so that we can close the WGLC.

>Kepeng provided feedback saying that the document should be experimental but I didn't see a response (and the document is still informational).

Yes, Klaus asked a similar question in his review, and we proposed an answer in our email to the WG (see Authors Response #1) as follows:

"We propose to leave the document as Informational as there is good precedence for this.  For example, a random search of Informational RFCs in the IETF stream shows that many Informational RFCs use RFC2119 language."

That is why we had not answered directly to Kepeng (i.e. we assumed he would see our response in the Email to Klaus).   Though obviously your question indicates that our approach was not the clearest.

>I asked a question about the mapping of HTTP parameters to CoAP options is. The conclusion was that there is no one-to-one mapping since there is no feature parity. As such, there is probably some text in the document that describes the limitations. (I haven't checked it yet.)

We have guidance for mapping of HTTP parameter to selected CoAP options in Sections 6 and 7:

https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#section-6

https://tools.ietf.org/html/draft-ietf-core-http-mapping-08#section-7

(Also, of course, the original CoAP RFC7252 had some guidance for this topic in https://tools.ietf.org/html/rfc7252#section-10.2 )

>I believe the HTTP-CoAP mapping document shows that any type of gateway is somewhat complex even for something as simple as a mapping from CoAP to HTTP (and vice versa). I suspect you guys have worked on an implementation to get all the details into the document.

As you know, the draft focuses on the reverse HTTP-CoAP proxy case, as the feeling in the WG was that the forward proxy case was well specified in RFC7252.  Two of the authors had separate early implementations of the reverse HTTP-CoAP proxy.  Since then there appears to be other open source implementations of various versions of the draft as discussed in F2F meetings and also apparent through Google.

>From your judgement do you believe there are no further open issues with the document or do you see any concerns with the small number of WGLC reviews? Did you reach out to some other implementers to get their input?

In my opinion, if we can close Klaus' comments we are in good shape.  We had multiple expert reviews of the draft over the years so we feel it has been reviewed quite extensively overall.  No, we did not reach out specifically to any other implementers for their input at the WGLC as the WG discussion on the topic especially over many F2F meetings has been quite vocal and active.  (Please note that we started the I-D that spawned this WG draft in January 2012.  So we have been working on and discussing this topic for over 4  years).

Best Regards,

Akbar

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Saturday, March 26, 2016 7:09 PM
To: Rahman, Akbar <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; Carsten Bormann <[email-masked]>
Subject: draft-ietf-core-http-mapping-07 -- was Re: [core] Agenda

Hi Akbar,

I took a look at the mailing list and noticed that the draft has gotten very little feedback during the WGLC. Given the number of people who had provided reviews earlier during the process (as captured in the acknowledgement section) one would hope that those folks could also briefly look at the document and say something (even if it is only a 'I have read it and it looks good.' comment.)

Klaus provided an extensive review for which received a detailed answer (around 6 months later). What I haven't seen is a confirmation from Klaus saying that he is happy with the way how the authors/editors handled his review. Basically, there was no discussion about the issues raised on the list. His review lead to a number of changes throughout the document, as it can easily be seen from the diff.

Kepeng provided feedback saying that the document should be experimental but I didn't see a response (and the document is still informational).

I asked a question about the mapping of HTTP parameters to CoAP options is. The conclusion was that there is no one-to-one mapping since there is no feature parity. As such, there is probably some text in the document that describes the limitations. (I haven't checked it yet.)

I believe the HTTP-CoAP mapping document shows that any type of gateway is somewhat complex even for something as simple as a mapping from CoAP to HTTP (and vice versa). I suspect you guys have worked on an implementation to get all the details into the document.

>From your judgement do you believe there are no further open issues with the document or do you see any concerns with the small number of WGLC reviews? Did you reach out to some other implementers to get their input?

Ciao
Hannes

On 03/26/2016 10:24 PM, Rahman, Akbar wrote:
> ".HTTP Mapping (15) Thomas Fossati (Akbar is the backup)
>
>> Andrew and I have to put in a revised agenda by Monday, so items
>> where do don't have a discussion leader and detailed objectives are a
>> bit endangered.
>>
>> Grüße, Carsten
>>
>>
>>
>>
>> Hannes Tschofenig wrote:
>>> Hi all,
>>>
>>> the upcoming IETF meeting. Too early to have that discussion? I
>>> don't think so given that the meeting is roughly in a week.
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 27 Mar 2016 12:59:25 +0200

Thanks for the quick response, Akbar.

On 03/27/2016 05:35 AM, Rahman, Akbar wrote:
>> Kepeng provided feedback saying that the document should be
>> experimental but I didn't see a response (and the document is still
>> informational).
> Yes, Klaus asked a similar question in his review, and we proposed an
> answer in our email to the WG (see Authors Response #1) as follows:
> 
> "We propose to leave the document as Informational as there is good
> precedence for this.  For example, a random search of Informational
> RFCs in the IETF stream shows that many Informational RFCs use
> RFC2119 language."
> 
> That is why we had not answered directly to Kepeng (i.e. we assumed
> he would see our response in the Email to Klaus).   Though obviously
> your question indicates that our approach was not the clearest.

I see the use of RFC 2119 language and the document type as orthogonal.

I personally do not have a strong opinion about the question of whether
the document should be Informational or Experimental (in general,
irrespectively of the content of the document).

I will review the document sometime during next week to see whether I
can provide any comments. It might be good to reach out to implementers
nevertheless since the question about implementation status typically
has to be included in the shepherd writeup. I believe the main audience
for this type of document are home gateway vendors.

Ciao
Hannes

---

From: "Kepeng Li" <[email-masked]>
Date: Sun, 27 Mar 2016 23:23:56 +0800

> tracker or haven't touched it for a while.

About draft-ietf-core-links-json-04, one open issue is to keep consistency
with CoRE Resource Directory draft.

Especially in section 8 of CoRE Resource Directory draft, it introduced
two new link format attributes: ins and exp.

We want to encode these two attributes into JSON and CBOR formats.

If there is any change (e.g. add more attributes or remove these
attributes) in Resource Directory draft, we need to keep up-to-date.

I am not sure if we have other open issues, Akbar or Carsten can add.

Kind Regards
Kepeng

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 27 Mar 2016 18:56:59 +0200

> We want to encode these two attributes into JSON and CBOR formats.

Right, giving them a numeric label (for the CBOR version) was the
technical change from -03 to -04.

However, there is no strict need to make this kind of change, as
encoding with a text label is fine, too; the numeric label is just an
optimization.  So we might want to decide to just ship the formats at
some point, even if we know the world is going to continue to change
around us.

(We also might want to decide to generalize the JSON/CBOR link formats
along the lines of what is being discussed in T2TRG.  Probably the best
of both worlds is to find a way to do this that is a highly decoupled
extension of what we have, so we can put the extension point into the
current format but gather some experience before actually defining such
an extension.  I hope we can work this out before Buenos Aires...)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Mar 2016 12:44:15 +0200

Hi Carsten,

I have re-read the Blockwise Transfer draft and the document does not
give me the impression that there is any specific need to tie it to
Object Security.

Can you explain what the relationship is?

I hope there is no plan to make the completion of Blockwise transfer
dependent on the progress of object security.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Mar 2016 14:14:31 +0200

Hi Hannes,

> Can you explain what the relationship is?

After the last call completed, we had a discussion on the IETF mailing
list how to employ object security in a block-wise transfer that spans
proxies.
If you secure only the complete representation, the cache in a proxy
might be poisoned by fake blocks, and you get an availability problem.
If you secure each of the blocks (and have a way for the proxy to be
part of a security association needed so it also can verify the blocks),
you can prevent that, but you still have to secure the way the entire
representation is composed from those blocks, and that might mean
additional components are needed in an object security protocol.

I agree that none of these considerations have a bearing on the
block-wise protocol itself, and this also was the resolution we reached
after the discussion.  But it was useful to have the discussion, and it
will inform the discussion about object security.

> dependent on the progress of object security.

No, as far as the CoRE WG is concerned, block-wise is done.
It is currently in IESG evaluation and on the agenda of the 2016-04-21
IESG telechat; Matthias Kovatsch is the shepherd.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Mon, 28 Mar 2016 13:36:41 +0000

Hi Hannes

Complementing Carsten’s explanation:

There is a conflict between being able to protect a message fragment
end-to-end between endpoints and giving any intermediate node the right to
refragment a message. Block operations performed by proxies cannot be
verified which has two consequences. Blockwise cannot be directly applied
to secure message fragmentation, and the Block option opens up for DoS by
any on-path adversary. I found this serious enough to warrant a security
consideration, which is included in -19.

It turns out that while plaintext CoAP block options passing proxies
cannot be protected in the way  blockwise works, they could potentially be
used end-to-end if you were certain there were no changes being made in
transfer, and that is something an object security solution could be used
for. This is one of the topics I’d like to discuss in the security section
on the CoRE agenda.

Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Mar 2016 16:44:50 +0200

Hi Carsten,

the observation that a proxy has negative impacts on security when
 * hop-by-hop communication security is used in combination with
 * terminating that communication at the proxy
is nothing that relates to the blockwise transfer itself.

In general, in such a setup the proxy has the power to change the
content, re-arrange data, inject new data, etc.

I understand that end-to-end security is important in such cases and of
course raises the question about the use of intermediaries in the first
place (particularly if they are supposed to make all sorts of
computations, like aggregation and analysis, on that data).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Mar 2016 16:58:59 +0200

Hi Goeran,

normally you would do the following:

 1) You take the entire payload (for example a firmware image).
 2) You add some security protection in the front.
 3) Then, you make it available for download.
 4) A server may then chunk it into pieces and delivery them separately
using the Blockwise Transfer mechanism.
 5) The client receives all the pieces, puts them together, verifies the
signature or MAC, and then updates the firmware.

This sequence of steps should be the same regardless of whether there is
a proxy that caches pieces or not.

So, what exactly is the concern here?

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Tue, 29 Mar 2016 09:57:04 +0000

Hi Hannes,

Such a solution only is not very robust against denial of service unless
there is additional security at lower layer or that it is possible to
protect fragments in sizes of certain upper limit such as in HTTP content
encryption. In the case of application layer security only, one would thus
have to invent something like the latter. While this is possible, it would
be very unfortunate if for each CoAP "feature" being defined, you need to
separately define the corresponding "e2e secure feature", instead of
making these considerations before standardizing the feature in question.
In particular as in the case of Block where all feaures of a secure
fragmentation scheme are present if you only were able to apply integrity
protection of each CoAP block message between the endpoints.

That is the problem statement. In terms of solution, it actually seems
possible to separate options intended for proxies from options intended
for endpoints without additional intrusion on CoAP. This means that you
can reuse Block, which although wasn't designed for end-to-end security,
of course does work in the absense intermediaries making changes.

Since you seem to be interested in the details here it goes: The
application layer security solutions presented so far which are applicable
to 3.1 and 3.2 of draft-hartke-core-e2e-security-reqs are based on
wrapping an unprotected CoAP message in a COSE object and send this in a
("protected") CoAP message.  The idea for simultaneously managing
end-to-end and proxy options is based on the concept of “duplicate”
options introduced in the latest version of OSCOAP: For certain options we
may allow the use of an “inner” option encrypted inside the COSE object
intended for the endpoint, and an “outer” option in the options part of
protected CoAP message intended for a proxy.

The block options could potentially be used in this way, allowing the
sending endpoint using an inner block option to fragment a large message
where each fragment can be protected end-to-end. This allows for a policy
of an upper limit for fragments which can be verified, the lack of which
was one of the concerns.

These secure fragments can, if necessary, in turn be fragmented by a proxy
using an outer block option. The receiving endpoint then first defragments
the protected CoAP message, then verifies and decrypts, then after
verifying and decrypting all protected fragments, defragments the
unprotected CoAP message which becomes verified by this process. (The
outer and inner options may be independent, so either the endpoint or the
proxy or both fragment, the scenario above is the case of “both”, which of
course is the most complicated.)

This is in brief what I propose to discuss in the CoRE WG under the topic
of "blockwise" in the security section.

Göran

---

From: Göran Selander <[email-masked]>
Date: Tue, 29 Mar 2016 09:57:23 +0000

Hi Hannes,

>is nothing that relates to the blockwise transfer itself.

See previous mail.

>place 

Intermediaries can also perform a security function by protecting
availability in terms of communication resources and power consumption of
constrained endpoints. I don’t see this as black or white, but as
conflicting requirements where different trade-offs are preferred
depending on the scenario. This is the topic of
draft-hartke-core-e2e-security-reqs, it would be interesting to hear your
comments on that.

>(particularly if they are supposed to make all sorts of

Those kind intermediaries are currently out of scope in the draft
referenced above, but one of the topics for discussion in that slot on the
CoRE agenda is what kind of intermediaries this analysis should encompass.
Currently it is forward proxy and pub-sub broker, we are considering to
add reverse proxy and translational proxy (e.g. HTTP-CoAP).

Göran