Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard

Eric Rescorla <ekr@rtfm.com> Tue, 11 June 2019 11:39 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A8120180 for <anima@ietfa.amsl.com>; Tue, 11 Jun 2019 04:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzrftcrLOUg9 for <anima@ietfa.amsl.com>; Tue, 11 Jun 2019 04:39:53 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0B3120144 for <anima@ietf.org>; Tue, 11 Jun 2019 04:39:49 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id p24so9046412lfo.6 for <anima@ietf.org>; Tue, 11 Jun 2019 04:39:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VYfMAWp7sO1GfgTPpDUfxFAAVK+471hMiwpaj0b8XpA=; b=Cg6nH17wS5fmIj5W8SKSbN5aJE9zZ+1h/J9ZWJwgBkXimA8iHhQZ2bjmrvzM7hBi7+ drKQDoOWvyoZmnYY1MnQSiuO+eSPn699iJfJ8GYoTd7B1zUaKBsvNa6GWy1CoFuKVL8l 6/jEpzcv5qTHRrO8kkedrbmHbx7FVaqhxMIJJ4Nlwklche2UiWQ6jyaZzwvI7xzBaukx alMqnqJpuxpvO3JZ9gxo62+JeLjzK0qIA5g7XUev+4qWVPAw7ZWh0mkbr4535lE9Scsz /Egt2nXExyYZfU/LI2lbIdP7p6vXBPiWW83kFw2OK3DYNN840/KEitLPiCustWNSHJFV 5smg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VYfMAWp7sO1GfgTPpDUfxFAAVK+471hMiwpaj0b8XpA=; b=RG5TEjkTDzK3bzvLjQqTxPx5xjjOFjKQCwvrfVxSUg/WDg9ZRH7giMxiSqhNLn4XPp jDTk57owLxwXWhATxdu+Plp/793itR/eRcR6tzYz83AG0ZB0oBV60cYIGoJ/Ei73c87E h/Ur/fOkoBnnGksYlzHb2QjTGFAQhFgQKfFHmf5w3oVM8V0C4rUZ7r/sbcbCVRcYqZCJ /ju7KEgbWDv1FdpyyDbecFu5tAS9GlltVkhuh5YVa6ciMK/3FDL6Yk3dgqNQAr2VV8rW j0babmUFDhFIKBxqdVE5jtFDhHLD/Io+cqZYNI5gAV0z1txBWGrUQawORke8Wukw45e4 DRgQ==
X-Gm-Message-State: APjAAAXDPqRJVUMjX0d9uCTyU4kCV4knvok/ttMcsls77xQDxxQCI3QH VYp+sQI3yNqf0qknIWxnekPrAS3A6COda7CqOuktIg==
X-Google-Smtp-Source: APXvYqxB5vppFSOTnkyWnn0LW6fOzDDeeA1ifYgUNQ23pfw590GT43uljI5Zol50ylaRqNFb26PFqq+BNqi83Ai31mk=
X-Received: by 2002:ac2:5922:: with SMTP id v2mr37286489lfi.180.1560253187971; Tue, 11 Jun 2019 04:39:47 -0700 (PDT)
MIME-Version: 1.0
References: <155847367546.2608.5031283783681425886.idtracker@ietfa.amsl.com> <02DFBB01-F7BA-4BCA-B8C5-CF14E8B7A6F4@cisco.com> <20190604192843.gbavqofsq4btcgx3@faui48f.informatik.uni-erlangen.de> <045A7809-CB6F-493E-B9F2-FBF563AD5378@cisco.com> <20190607211720.y63ysayeqtkgi3lj@faui48f.informatik.uni-erlangen.de> <60BB0A11-A12B-4EA5-9379-12C75100D64C@cisco.com> <77dc7db3-e281-2475-6909-c9c5a982f973@gmail.com> <CABcZeBPcJN9eweSW8ayVAbyehjizycpLN2=dDe1txZEh8dm7QQ@mail.gmail.com> <D3CE9EEE-98B4-46B3-B76B-60E40585B150@cisco.com>
In-Reply-To: <D3CE9EEE-98B4-46B3-B76B-60E40585B150@cisco.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 11 Jun 2019 04:39:11 -0700
Message-ID: <CABcZeBMrnO3-WkQS3-eM+T==GbsbeEyuboFXHRSytGL7YGc8tA@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Toerless Eckert <tte@cs.fau.de>, Ignas Bagdonas <ibagdona@gmail.com>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, IETF discussion list <ietf@ietf.org>, anima-chairs@ietf.org, Anima WG <anima@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000077652058b0ac124"
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/wUMhCULAQ_FHUcU1E60P0EdI52A>
Subject: Re: [Anima] Last Call: <draft-ietf-anima-bootstrapping-keyinfra-20.txt> (Bootstrapping Remote Secure Key Infrastructures (BRSKI)) to Proposed Standard
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2019 11:40:04 -0000

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 <lear@cisco.com> wrote:

> Hi
>
> On 10 Jun 2019, at 13:16, Eric Rescorla <ekr@rtfm.com> 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 <tte@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, ..
>> >>>>>
>> >>>>> 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@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
>> >>>>>> ietf@ietf.org mailing lists by 2019-06-04. Exceptionally,
>> comments may be
>> >>>>>> sent to iesg@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/
>> >>>>>>
>> >>>>>> 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@ietf.org
>> >>>>>> https://www.ietf.org/mailman/listinfo/anima
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>> _______________________________________________
>> >>>>> Anima mailing list
>> >>>>> Anima@ietf.org
>> >>>>> https://www.ietf.org/mailman/listinfo/anima
>> >>>>
>> >>>>
>> >>>> --
>> >>>> ---
>> >>>> tte@cs.fau.de
>> >>>
>> >>
>> >>
>> >>
>> >>> _______________________________________________
>> >>> Anima mailing list
>> >>> Anima@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/anima
>> >>
>> >>
>> >> --
>> >> ---
>> >> tte@cs.fau.de
>> >
>> > _______________________________________________
>> > Anima mailing list
>> > Anima@ietf.org
>> > https://www.ietf.org/mailman/listinfo/anima
>> >
>>
>>
>