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
Attachment:
signature.asc
Description: Message signed with OpenPGP
