> On 11 Jun 2019, at 13:39, Eric Rescorla <e...@rtfm.com> wrote: > > As I mentioned in another email exchange, why not use two domains under > .example?
I missed that. That would be fine with a good example. Eliot > > On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear <l...@cisco.com > <mailto:l...@cisco.com>> wrote: > Hi > >> On 10 Jun 2019, at 13:16, Eric Rescorla <e...@rtfm.com >> <mailto:e...@rtfm.com>> wrote: >> >> >> That's a little unfortunate from the perspective of this attack because .com >> is a public suffix [0] whereas example.com <http://example.com/> is not. >> > > > After a private exchange, I understand the nature of Eric's concern. The > issue is that you want to demonstrate separate administrative entities, and > subdomains generally wouldn’t that point clear. The problem is that the > obvious examp1e is already registered. Thoughts? > > Eliot > >> -Ekr >> >> [0] https://publicsuffix.org/ <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 <t...@cs.fau.de >> >>>> <mailto:t...@cs.fau.de>> 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 <http://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-secret...@ietf.org >> >>>>>> <mailto:iesg-secret...@ietf.org>> 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 >> >>>>>> i...@ietf.org <mailto:i...@ietf.org> mailing lists by 2019-06-04. >> >>>>>> Exceptionally, comments may be >> >>>>>> sent to i...@ietf.org <mailto:i...@ietf.org> 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/ >> >>>>>> >> >>>>>> <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/ >> >>>>>> >> >>>>>> <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/2816/> >> >>>>>> https://datatracker.ietf.org/ipr/3233/ >> >>>>>> <https://datatracker.ietf.org/ipr/3233/> >> >>>>>> https://datatracker.ietf.org/ipr/2463/ >> >>>>>> <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@ietf.org <mailto:Anima@ietf.org> >> >>>>>> https://www.ietf.org/mailman/listinfo/anima >> >>>>>> <https://www.ietf.org/mailman/listinfo/anima> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>>> _______________________________________________ >> >>>>> Anima mailing list >> >>>>> Anima@ietf.org <mailto:Anima@ietf.org> >> >>>>> https://www.ietf.org/mailman/listinfo/anima >> >>>>> <https://www.ietf.org/mailman/listinfo/anima> >> >>>> >> >>>> >> >>>> -- >> >>>> --- >> >>>> t...@cs.fau.de <mailto:t...@cs.fau.de> >> >>> >> >> >> >> >> >> >> >>> _______________________________________________ >> >>> Anima mailing list >> >>> Anima@ietf.org <mailto:Anima@ietf.org> >> >>> https://www.ietf.org/mailman/listinfo/anima >> >>> <https://www.ietf.org/mailman/listinfo/anima> >> >> >> >> >> >> -- >> >> --- >> >> t...@cs.fau.de <mailto:t...@cs.fau.de> >> > >> > _______________________________________________ >> > Anima mailing list >> > Anima@ietf.org <mailto:Anima@ietf.org> >> > https://www.ietf.org/mailman/listinfo/anima >> > <https://www.ietf.org/mailman/listinfo/anima> >> > >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
