Thanks, Eliot,
re-reading 10.3, my impression is:
a) The use of TOFU in 10.3 seems to exceed the explanatory definition in 1.2.
The sentence stubs in 103 mentioning TOFU also don't seem to add value, the text
doesn't become IMHO worse if they are simply removed. And i am sure
there can easily be similar non-cyptographic leap of faiths in sales integration,
or consortium memberships trust chaing establishment.
b) The text could IMHO be crisper:
"will have no problem collaborating with it's MASA" ->
"will have no problem collaborating with it's malicious MASA" ->
"the domain (registrar) still needs to trust the manufacturer" ->
"the domain (registrar) still needs to authenticate the MASA" ?
(i hope the latter is the correct interpretation of the text)
Cheers
Toerless
On Tue, Jun 04, 2019 at 06:33:00PM +0200, Eliot Lear wrote:
> Just on this text:
>
> In Section 10.3 the following text exists:
>
> o A Trust-On-First-Use (TOFU) mechanism. A human would be queried
> upon seeing a manufacturer's trust anchor for the first time, and
> then the trust anchor would be installed to the trusted store.
> There are risks with this; even if the key to name is validated
> using something like the WebPKI, there remains the possibility
> that the name is a look alike: e.g, c1sco.com, ..
>
> First, this isn???t REALLY Trust-On-First-Use, and I would prefer that the term be replaced with something like "out-of-band approval". This would also be a good area for certification services to step in to indicate the trustworthiness of a manufacturer.
>
> Eliot
>
> > On 21 May 2019, at 23:21, The IESG <iesg-secretary@xxxxxxxx> wrote:
> >
> >
> > The IESG has received a request from the Autonomic Networking Integrated
> > Model and Approach WG (anima) to consider the following document: -
> > 'Bootstrapping Remote Secure Key Infrastructures (BRSKI)'
> > <draft-ietf-anima-bootstrapping-keyinfra-20.txt> as Proposed Standard
> >
> > This is a second Last Call. IoT Directorate review was done after the ANIMA
> > WG Last Call and consensus to request the publication, and that review resulted
> > in substantial changes to the document.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action. Please send substantive comments to the
> > ietf@xxxxxxxx mailing lists by 2019-06-04. Exceptionally, comments may be
> > sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of
> > the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> > This document specifies automated bootstrapping of an Autonomic
> > Control Plane. To do this a remote secure key infrastructure (BRSKI)
> > is created using manufacturer installed X.509 certificate, in
> > combination with a manufacturer's authorizing service, both online
> > and offline. Bootstrapping a new device can occur using a routable
> > address and a cloud service, or using only link-local connectivity,
> > or on limited/disconnected networks. Support for lower security
> > models, including devices with minimal identity, is described for
> > legacy reasons but not encouraged. Bootstrapping is complete when
> > the cryptographic identity of the new key infrastructure is
> > successfully deployed to the device but the established secure
> > connection can be used to deploy a locally issued certificate to the
> > device as well.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/
> >
> > The following IPR Declarations may be related to this I-D:
> >
> > https://datatracker.ietf.org/ipr/2816/
> > https://datatracker.ietf.org/ipr/3233/
> > https://datatracker.ietf.org/ipr/2463/
> >
> >
> >
> > The document contains these normative downward references.
> > See RFC 3967 for additional information:
> > rfc8368: Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) (Informational - IETF stream)
> >
> >
> >
> > _______________________________________________
> > Anima mailing list
> > Anima@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/anima
>
> _______________________________________________
> Anima mailing list
> Anima@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/anima
--
---
tte@xxxxxxxxx
