[Secdispatch] my thoughts on the EDHOC interim

[Benjamin Kaduk <[e-mail]>]

Hi all,

Thanks to everyone who attended the interim -- I know it was not a great
time zone for many people, but you stuck to it.

My sense coming out of the session was that it's pretty clear there are
some wide areas of applicability where EDHOC is useful and a clear
improvement over the pure-PSK methods currently in use.  It seems like,
in broad terms, what we're currently stumbling over is just the process
of bringing new work to the IETF. Among other things, we evaluate proposed
work in a broad context that includes both the present state of deployment
(if any) in the problem space and the present state of similar protocols.

In particular, publishing as Proposed Standard in the IETF RFC stream
means (in general; there can be exceptions) that:

- the IETF has change control over the technology

- there is IETF consensus to produce a solution in the problem space in
  question and on what the problem space in question is

- there is IETF consensus that the technology in question is a good
  solution to the problem at hand.  It need not be the perfect solution
  if the value from publishing and implementing earlier outweights the
  costs of the delay to tweak it further; similarly, if an existing
  technology can be used to meet the need then there is a higher bar for
  introducing something completely new, depending on the degree of
  similarity and the nature of the protocol in question.

I am seeing several people try to assess the "good solution to the
problem at hand" portion and run into trouble because the "problem at
hand" was not clear enough (to them) to produce a clear answer -- we had
several alternate solutions proposed but no consensus on whether they
actually solve the problem at hand, largely because the "problem at hand"
has been hard to nail down in a way that can readily be assessed.  As such,
it may even be premature to try to tackle the "good solution to the problm
at hand" with the current definition, which is in some ways being described
as a pure minimization function with no cutoff for "good enough" or
"diminishing returns".  (From a mathematical sense, it's pretty clear that
the function thusly described has no absolute minimum, so our search would
never terminate.)

Luckily, it seems that our discussion of frame sizes and power
consumption can point us to a clear framing of *a* problem that does
have clear and actionable success criteria.  This need not be a "fully
general" space (if such a thing is even possible for constrained
devices), but if the relevant deployed base is large, even a solution
targeted to that space would have value.  (Presumably the solution would
still be useful in adjacent problem spaces as well, even if they were
not explictily targetted.)

As Martin noted, the standard questions we look at in BoF sessions can
also be used to assess proposed new work outside of a BoF, and it may be
useful to consider this work in the context of those questions:

1. What is the problem we are faced with?                                           
2. Is the problem understood and narrowly scoped?                                   
3. Do we believe it is possible to engineer a solution?                             
4. (stretch objective) Is this particular proposal a good basis for working on?     

Thanks to everyone for continuing to work through this topic in a
thoughtful and methodical manner.

-Ben