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

Stephen Farrell <> Mon, 31 July 2017 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C85BD132620 for <>; Mon, 31 Jul 2017 12:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WpkxdaHmowQ2 for <>; Mon, 31 Jul 2017 12:23:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA364126B71 for <>; Mon, 31 Jul 2017 12:23:01 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 447BFBE4C; Mon, 31 Jul 2017 20:22:59 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HsRmOsnpHvrM; Mon, 31 Jul 2017 20:22:53 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 2C1C7BE39; Mon, 31 Jul 2017 20:22:53 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1501528973; bh=nkHhM7iMN4Lym5eKMCNHZglIFREWrnh0xzjWZ3+ln6Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HK4q3KURjcFnEwvc37MX/4iWB2GNCGIjGLQcTSJZJIwog0S3gNg/LriDucm+a5SS7 B4J3dN0gJ3IfOm/fWyJSr5XhSCWEhmeZVQmp4NzL4rEd956LwRtPBHjN+OvfK8PImI 5wUPxJLqwoi9mhNnE9yCIsQ1n2fJ7FbJJIRZqYv0=
To: Ted Lemon <>, Michael Richardson <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Mon, 31 Jul 2017 20:22:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2TtH8Nr3G7vxgJIO1v02NgI9fbC1PRj3f"
Archived-At: <>
Subject: Re: [homenet] Ted's security talk at IETF99: DNCP Security
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Jul 2017 19:23:04 -0000

On 31/07/17 19:00, Ted Lemon wrote:
> I don't know how to make that work without a fake domain tree.
> Can't we just use <>?
I think the protocols would work fine, but I'm not sure there's
a current challenge type that'd work here, for LE or any similar
service. (The current set of challenges in the acme spec is at

For my main home router (a Turris), I setup a VPN connection so
that the AAAA for a name I control is routed to the Turris when
the VPN is up, and then I just used [1] to talk to LE
and all that works just fine and gets rid of the annoying browser
insecurity warning when I use luci.

(I further cheat by only having that VPN up when I need to talk
to LE for renewal checks and otherwise just resolve the name
using 10/8 inside the home, but I'm sure there're better options.)

So the plumbing/protocols all do work if you have a name and
address that works from the CA service provider POV. It's just
that almost nobody can do that today.

Is this something where it'd be worth trying to get a few folks
from the various communities on a call to see if we can come up
with something that might work for the openwrt/lede type cases?

If so, I'd be happy to try set that up in a month or so, when
holliers are done and I'm supposedly gonna be a chair-like being:-)
I'd be happy to try that even if the chances of a Eureka! moment
aren't very high. (And btw, the reason I suggest that scope is
that I figure commercial device vendors can figure out the cert
issuance part just fine already, and with better assurance, but
probably have the same issues with browser trust stores as do the
openwrt/lede folks, so I'm not suggesting excluding commercial
device vendors, just limiting the scope to stuff that could be
worked on today by anyone if we did have that Eureka! moment.)