Re: [homenet] Ted's security talk at IETF99: DNCP Security

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 01 August 2017 00:20 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2EF131CB1 for <homenet@ietfa.amsl.com>; Mon, 31 Jul 2017 17:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LKWiJBXm_u-S for <homenet@ietfa.amsl.com>; Mon, 31 Jul 2017 17:20:24 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8897D131CAE for <homenet@ietf.org>; Mon, 31 Jul 2017 17:20:24 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 07E022009E; Mon, 31 Jul 2017 20:22:10 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C634A80243; Mon, 31 Jul 2017 20:20:23 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ted Lemon <mellon@fugue.com>
cc: homenet@ietf.org
In-Reply-To: <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com>
References: <3725.1501514462@obiwan.sandelman.ca> <52E1C5A0-FC0E-46A5-9016-AA95FB3DC1CB@fugue.com> <3184.1501522914@obiwan.sandelman.ca> <5A407EA3-AC8B-44A7-8EC2-8242480027FE@fugue.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Mon, 31 Jul 2017 20:20:23 -0400
Message-ID: <27345.1501546823@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/PpxZhy7bWJMTKHXVPke5lqsVyKs>
Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Aug 2017 00:20:26 -0000

Ted Lemon <mellon@fugue.com>; wrote:
    > That partly gets rid of the security exception on each access to the
    > web interface: provided the web browser loads the new trust anchor.


    > I don't know how to make that work without a fake domain tree. Can't we just
    > use ACME+letsencrypt.org?

I hadn't thought about that.
The objections I can think about involves three kinds of things:
  a) do they really want this kind of traffic?
  b) the certs issued will go into their cert transparency list, and I think
     that means we lose privacy.
  c) to make it work, they have to verify things.  IPv6 makes the
     connectivity easy to arrange, but it seems like it's a big exposure for
     the device.  We are talking more than just routers... I'm thinking
     printers and all sorts of things.

    > Sure. The question is, what value does the PKI cert add here? I agree that
    > having a cert that validates is good for the web UI, but I don't see how it
    > helps in establishing trust.

It doesn't establish initial trust, it gives the user a trusted icon in their
browser once we have initial trust.

    > I would be tempted to do something like what Christian is doing with DNSSD
    > privacy: print a QR code on the box, take pictures of all the QR codes with
    > your smartphone, and then use your smartphone app to bootstrap trust using
    > those QR codes. You could do something similar by just flashing the front
    > panel LEDs really fast when the "pair" button is pressed, and have the
    > smartphone decode that, as is being done with exfiltration malware now. I
    > suspect there's code we could download... :)

I think that these are all really good ways to establish initial trust.
BRSKI mentions the whole category at:
  https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-07#section-4.2

  3.  The Pledge MAY have an operational mode where it skips Voucher
      validation one time.  For example if a physical button is
      depressed during the bootstrapping operation.  This can be
      useful if the vendor service is unavailable.  This behavior SHOULD be
      available via local configuration or physical presence methods to
      ensure new entities can always be deployed even when autonomic
      methods fail.  This allows for unsecured imprint.

Christian's comments in DNSSD (which I also watched today) is right though:
for many applications in *discovery* is important you probably don't want
certs, because they reveal too much, and the relationship is too ephermeral.
The link between Dave's Laptop and Dave's Cool Printer is probably longer.

--
Michael Richardson <mcr+IETF@sandelman.ca>;, Sandelman Software Works
 -= IPv6 IoT consulting =-