Re: [core] comments on draft-hartke-core-e2e-security-reqs

[Göran Selander <[e-mail]>]

Jim

Thanks for spending the time (and the wine).

Sorry for the delay, we wanted to respond directly to your comments with
an updated version of the draft, but since it still is not quite ready I
just want to acknowledge your mail. We were already in the process of
making an update trying to fix the repetitiveness of the -00 version, and
instead build on generic issues, focus on the endpoints rather than the
middle entities etc. so those and related comments makes very much sense.

Then there are other parts that we may not be able to discuss within the
draft, like e.g. various combinations of different type of proxies (though
should be possible to infer from the draft), and some types of
“conversations” which are not yet defined for CoAP (like multicast with
multicast reply).

Stay tuned.


Göran


On 2016-04-26 20:16, "Jim Schaad" <[e-mail]> wrote:

>After the meeting I tried to do a front to back reading of this document
>several times.  I regret to note that I only succeeded once (after about 4
>glasses of wine), but will note that I was reading this on a Kindle and
>therefore it suffered both from a smaller screen and some formatting
>errors.
>
>I would like to suggest some major document overhauls that I think would
>both improve the ability to read the document and might (but probably will
>not) address some of the concerns that Hannes raised at the F2F meeting.
>
>The document is very repetitive.  This makes the document harder to read
>as
>one get confused and bored by dealing with the same statements over and
>over
>again.  To deal with this, I would suggest that things be built on rather
>than repeated. This means that one can start with a generic proxy in the
>first section and deal with the issues of that case and then the rest of
>the
>time one can just say - those things plus the following without
>repetition. 
>
>I don't like the scenario based structure of the document.  One of the
>problems that I have is that the list of scenarios is going to be endless
>and difficult to think about in an exhaustive manner.  One starts with the
>questions of what happens when you have a situation of dealing with
>scenario
>#1 and then #2 and then what happens when you compose #1 and #2 (or #2 and
>#1).  I think that it would be better to focus on the different types of
>proxies that can be identified and then go on from there.  This makes it
>easier to think about what needs to be placed in a new document that
>defines
>a new proxy type as well.
>
>For each different proxy type I would look at covering the following:
>** Generic Description of what the proxy type does
>** What it means for the proxy to be 1) untrusted, 2) semi-trusted and 3)
>fully trusted.  Note that not all of these are applicable to any given
>proxy
>type.  (For example, if one looks at a NAT proxy then only untrusted makes
>sense.)
>** An example scenario for each of the different trust levels for the
>proxy.
>This is where there is the greatest problem in trying to come up with real
>world rather than academic examples might be the hardest thing to do.
>** Look at the threats and requirements for each trust level building on a
>base.  I.e. start the list with a single requirement of "Incorporate the
>following requirements by reference A1, A2, A3, A4".
>
>Start the document with some type of generic proxy.  I would suggest a NAT
>proxy as this is something that is simple and easy to talk about as it
>does
>not do any changes to the CoAP message and thus is trivial to understand.
>
>Include a description of the above security levels and what they imply in
>terms of key sharing and trust sharing.
>
>Include a description of how one should think about composing proxies
>together into a single unit.  Depending on how one does the analysis, I
>think that this can be treated as dealing with the capabilities of each
>proxy separately if they are combined into a single unit and can easily be
>treated as separate things when they are not treated as a single unit.
>Part
>of the question is what one wants to say about proxies that collude
>together
>as oppose to be the same proxy.
>
>(day #2)
>
>I can understand there might be a desire to talk about conversations
>between
>entities.  However, these should focus on the conversation and ignore the
>middle entities.  That is there are going to be generic issues that deal
>with the following situations:
>
>1) Send message from A to B.
>2) Multicast message from A to Group B
>3) Round trip from A to B.
>4) Multicast message from A to Group B w/ single cast reply
>5) Multicast message from A to Group B w/ multi-cast reply to group B
>(assuming that A is in Group B)
>
>Jim
>
>