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

["Jim Schaad" <[e-mail]>]

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