Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

[Toerless Eckert <[e-mail]>]

Ok, now i got you (i hope ;-).

I really liked the c1sco example (not sure if we should mention a real
company name in such an rfc someone not reading the draft might take
offense, maybe examp1e.com insted though).

But taking your thought into account: There is a fundamental difference
betwen TOFU and out-of-band-authentication/approval (pick a term),
and the fact that different such mechanisms may have (often human)
weaknesses does not change this fundamental difference ??

Maybe you want to propose text ?

Cheers
   Toerless

On Wed, Jun 05, 2019 at 01:09:09PM +0200, Eliot Lear wrote:
> Hi Toerless,
> 
> > On 4 Jun 2019, at 21:28, Toerless Eckert <[e-mail]> wrote:
> > 
> > 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.
> 
> My point is that those are no longer leaps of faith.
> 
> Eliot
> 
> > 
> > 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 <[e-mail]> 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
> >>> [e-mail] mailing lists by 2019-06-04. Exceptionally, comments may be
> >>> sent to [e-mail] 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/anima
> >> 
> > 
> > 
> > 
> >> _______________________________________________
> >> Anima mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/anima
> > 
> > 
> > --
> > ---
> > [e-mail]
> 



> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima


-- 
---
[e-mail]