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

[Eric Rescorla <[e-mail]>]

On Sat, Jun 8, 2019 at 4:21 PM Brian E Carpenter <
[e-mail]> wrote:

> On 09-Jun-19 01:37, Eliot Lear wrote:
> >
> >
> >> On 7 Jun 2019, at 23:17, Toerless Eckert <[e-mail]> wrote:
> >>
> >> 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).
> >
> > This is a bit tricky with the glyph attack, but certainly the base
> should be
> > example.com.
>
> Can you use null.example.com and nu11.example.com?
>

That's a little unfortunate from the perspective of this attack because
.com is a public suffix [0] whereas example.com is not.

-Ekr

[0] https://publicsuffix.org/

>
>     Brian
>
> >> 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 ??
> >
> >
> > I think the key is that humans oughtn’t rely solely on a visual
> inspection of whatever is presented in front of them, but rather that they
> might rely on alternative inputs, such as recommendations made by the
> registrar provider, or federated services.
> >
> >
> >>
> >> Maybe you want to propose text ?
> >
> > Manual approval by administrator or selection by administrator.
> >
> > Eliot
> >>
> >> 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]
> >
> > _______________________________________________
> > Anima mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/anima
> >
>
>