On 11 Jun 2019, at 13:39, Eric Rescorla < ekr@xxxxxxxx> 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 Hi On 10 Jun 2019, at 13:16, Eric Rescorla < ekr@xxxxxxxx> 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
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
>
|
