Subject: [Iot-onboarding] draft-sarikaya-t2trg-sbootstrapping-05 is really good

From: Michael Richardson <[email-masked]>
Date: Sun, 02 Dec 2018 20:38:01 -0000

B. Sarikaya, M. Sethi and D. Garcia-Carillo
have done some very good work with 
  https://datatracker.ietf.org/doc/html/draft-sarikaya-t2trg-sbootstrapping-05

The intro section deals with "bootstrapping" vs "onboarding", and there is
also the term "enrollment"... 

Section 3 does not mention BRSKI, and it probably should, but you mention it
in section 4... not sure I understand why. I guess it is a managed method?

"Opportunistic and leap-of-faith methods"

I think that this category should be split up, and distinguish between
methods that are Opportunistic (no memory, no implied trust), those which
are LoF followed by Trust on First Use.

      Additionally, various
      online services such as Gmail and Facebook allow anyone to create
      a new identity during the initial setup and later only verify the
      continuity of the same identity.

Not sure I understand this, maybe a reference would be worth it.
Since I don't understand it, I don't know if it fits.

section 4.1 lists a bunch of one-touch (1+) methods as managed,
which I actually find puzzling.  I do not consider many of the methods listed
as enrollment or onboarding methods.  (By the (a) defintion of Introduction)
They are all (b) methods, yet you include BRSKI there.

[I-D.ietf-netconf-zerotouch] is an RFC8366 based mechanism, similar to BRSKI,
but using a different set of assumptions about communications, including none
(USB key).

4.2: I'm told that Thread version n+1 uses BRSKI.

DPP:    DPP (Device Provisioning Protocol) [dpp] is a 3 message
   authentication protocol currently being standardized by the WiFi
   Alliance for devices that rely on IEEE 802.11 link-layer for
   communication.  The current DPP specification is only aimed at
   networks that use WPA2-PSK (also known as WPA2-Home) for network
   access authentication. 

I was unaware that it was limited WPA2-PSK networks. I don't think that is
true. Maybe WPA2-PSK type networks are just the sweet spot where it makes
most sense.

Generally, I really like your section 1,2.
Section 3 could use a bit of work.

I don't think the survey in section 4 is worthwhile as is.

What I'd like to see is a clear set of terminology (a la RFC7228) that we can
subsequently use.  Some really clear clarification of what some terms mean.
I don't care if due to clashes with other word uses, we "Property Red",
"RFC89AB-bootstrapping"... (or use Caribean island names or whatever).

We could stop at that point, and then let the various documents apply the
terminology to themselves.
   "According to RFC89AB terminology, BRSKI is has Property Red, and
   should be categorized into the set of Jamaican-Zero-Touch protocols"

I think that getting section 4 nailed down is not very useful in an IETF
or IRTF specification.   It will take too long, and might cause arguments
that can't be resolved, even in IETF publication time.

Instead, write a survey article for a journal (the IETF Journal is always
looking for stuff...) that applies your terminology to various protocols.  

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 4 Dec 2018 10:16:51 -0600

Hi Michael,

Thanks for the review and nice words.
We noticed that for T2TRG you used wrong address and I now corrected it so
that the group can see your mail.
We are going to send a detailed reply soon, stay tuned.

Regards,
Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 Dec 2018 10:41:43 -0600

Hi Michael, all,

Please see inline.

> in section 4... not sure I understand why. I guess it is a managed method?
Now in Revision 06, it does.

> are LoF followed by Trust on First Use.
Sure Rev. 06 will fix this.

> Since I don't understand it, I don't know if it fits.
This text will be removed in Rev. 06.

> They are all (b) methods, yet you include BRSKI there.
Well they are mostly (b) methods. This draft historically was aimed at
documenting the existing (b) methods and the addition of (a) methods are
more recent, so we intended to do both.

> but using a different set of assumptions about communications, including
Sure, we add this text also in Rev. 06. Sorry we had missed the reference
of RFC 8366.

> true. Maybe WPA2-PSK type networks are just the sweet spot where it makes
Now this is all fixed in Rev. 06.

> Section 3 could use a bit of work.
Regarding your comments below, here what our views are:

Your comments on the classification: we will add a few terms to the
terminology section.
Making it like RFC 7228 is a completely different endeavor, a completely
new draft.
But it is not in our draft's scope. We have targeted t2trg charter item
when we wrote Section 4. Actually this section already was revised in
response to the reviews made, including yours which was an in-depth review.

I am personally interested in co-authoring such a terminology for
onboarding draft.
Maybe we can undertake such an activity on the context of the new
onboarding effort in IETF.

Regards,
Behcet

Regarding his comments on the classification, I suggest that we add a few
definitions to the terminology section
in reply to his request.
Making it like RFC 7228 is a complete makeover and it would amount to a
completely new draft and is not in our draft's scope.
Maybe the new onboarding effort in IETF may target something like this.

I suggest that we reply to his Section 4 comments saying that there is a
T2TRG charter item on this and that is what our draft corresponds to.