> 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. > > 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
