Re: [T2TRG] draft-sarikaya-t2trg-sbootstrapping-05 is really good

Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 04 December 2018 16:17 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38975130F0B for <t2trg@ietfa.amsl.com>; Tue, 4 Dec 2018 08:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_iPwkwmhtb9 for <t2trg@ietfa.amsl.com>; Tue, 4 Dec 2018 08:17:08 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8516130ECA for <t2TRG@irtf.org>; Tue, 4 Dec 2018 08:17:04 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id z5so16580090wrt.11 for <t2TRG@irtf.org>; Tue, 04 Dec 2018 08:17:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=ZN3uyE6uQw90AOqYbpaNtXItUerUDnwiztcMRxFPpJk=; b=uJO7hSxilxEdsqBiRBCybnCkTEdLVWJIOcyliJ4QiR0QbsOREG7HL9jgN99YfjpTeq JW4x0reLCTayeZjDjh6XkG3C7QMKsEFflRB37dqZ9gtSyX9p0NmrkYKy+fbPAA3HAP+R ZYHTNQepoGJpxpOGLoUjkqdYyCHnYIcD/Xl1nm1H+3DVE7n4O83CSjTbmBX6D+dwzI23 zbExnaoZtxDg7PXAPINw3nsLL7d6wtlDK7N3/IL2EXpZd2WSM0wK+Pngo4lnfWF8zTNJ 3mqbQfDtVpcl75qe+nd5LSq+YwaQJ3fg9l0lMUzhdtM0yX9CKReCJDu1UfiHWkM6Jtlc oeVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=ZN3uyE6uQw90AOqYbpaNtXItUerUDnwiztcMRxFPpJk=; b=NNWW7X2OqIrxGxLcKqPySEy5PzbJsK5PHEnVMlWjjI4mktMvxdi5ZjUaFZjMo1Sn2i WkTWUtqmb6G+8sUmQadXr7/48BON4FoxqjOYmu4kyMhDpyGt92Csr6UbIgaoI5mPzGIJ 7xbxnmM0W7SkNvwVVQgkzqKdjkbmAP+O95drqNkQmqSLAOKKq9l6Rcgu61doosN2eYDy oPrEDbSF4xcthHQHTatB18mlyyThMAbZAr9TFMCxZ2mDZdFim4Oorcqv10gUdeJ1EpPO pBzCXvY3fVYkzULUN6ydTj7pwu5efEQ2xrsoBNf6LzHbPTmiJgkW9X7drsqkuMdbK14l Zx3w==
X-Gm-Message-State: AA+aEWbXBfdjc/GVWvuPhzl2qdPOk19eJKU1qB1P3ombjrms6U37flU8 3Bb2wd4N76A/kEgNX5bivHLFMqLNUq1Mqf09mdA=
X-Google-Smtp-Source: AFSGD/V4DljyqZw+nqVfw+UmGklPlnLhat1p/xXnSOlnOQ7VMW/OLdyMmh0NLFBuQOi8BAhRO5y4pXcvCZn9QATYKIM=
X-Received: by 2002:adf:9c8a:: with SMTP id d10mr18193417wre.244.1543940223397; Tue, 04 Dec 2018 08:17:03 -0800 (PST)
MIME-Version: 1.0
References: <13966.1543783081@dooku.sandelman.ca>
In-Reply-To: <13966.1543783081@dooku.sandelman.ca>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Tue, 04 Dec 2018 10:16:51 -0600
Message-ID: <CAC8QAcdzjS4OhPxcoSw-X8ad0adwCwJEQKqcN+ZufzpBu13qBw@mail.gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "t2trg@irtf.org" <t2TRG@irtf.org>
Cc: iot-onboarding@ietf.org, draft-sarikaya-t2trg-sbootstrapping@ietf.org
Content-Type: multipart/alternative; boundary="00000000000091f44e057c349898"
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/a7V0wrwyCA_yHZlggFa-SGNPOfE>
Subject: Re: [T2TRG] draft-sarikaya-t2trg-sbootstrapping-05 is really good
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 16:17:13 -0000

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

On Sun, Dec 2, 2018 at 2:38 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>