On Sat, Jun 8, 2019 at 4:21 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
On 09-Jun-19 01:37, Eliot Lear wrote:
>
>
>> 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.
Can you use null.example.com and nu11.example.com?
That's a little unfortunate from the perspective of this attack because .com is a public suffix [0] whereas example.com is not.
-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@xxxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/anima
>>
>>
>> --
>> ---
>> tte@xxxxxxxxx
>
> _______________________________________________
> Anima mailing list
> Anima@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/anima
>
