As I mentioned in another email exchange, why not use two domains under ..example?
On Tue, Jun 11, 2019 at 1:40 AM Eliot Lear <[email protected]> wrote: > Hi > > On 10 Jun 2019, at 13:16, Eric Rescorla <[email protected]> wrote: > > > That's a little unfortunate from the perspective of this attack because > .com is a public suffix [0] whereas 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/ > >> >> 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 <[email protected]> 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 <[email protected]> >> 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 >> >>>>>> [email protected] mailing lists by 2019-06-04. Exceptionally, >> comments may be >> >>>>>> sent to [email protected] 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 >> >>>>>> [email protected] >> >>>>>> https://www.ietf.org/mailman/listinfo/anima >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>>> _______________________________________________ >> >>>>> Anima mailing list >> >>>>> [email protected] >> >>>>> https://www.ietf.org/mailman/listinfo/anima >> >>>> >> >>>> >> >>>> -- >> >>>> --- >> >>>> [email protected] >> >>> >> >> >> >> >> >> >> >>> _______________________________________________ >> >>> Anima mailing list >> >>> [email protected] >> >>> https://www.ietf.org/mailman/listinfo/anima >> >> >> >> >> >> -- >> >> --- >> >> [email protected] >> > >> > _______________________________________________ >> > Anima mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/anima >> > >> >> >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
