On 09-Jun-19 01:37, Eliot Lear wrote: > > >> On 7 Jun 2019, at 23:17, Toerless Eckert <tte@xxxxxxxxx> 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? 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 <tte@xxxxxxxxx> 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 <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 >>> >> >> >> >>> _______________________________________________ >>> Anima mailing list >>> Anima@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/anima >> >> >> -- >> --- >> tte@xxxxxxxxx > > _______________________________________________ > Anima mailing list > Anima@xxxxxxxx > https://www.ietf.org/mailman/listinfo/anima >