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

Ted Lemon <> Mon, 31 July 2017 15:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 611B9132504 for <>; Mon, 31 Jul 2017 08:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8dZIlfRkU-et for <>; Mon, 31 Jul 2017 08:28:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E64901324D4 for <>; Mon, 31 Jul 2017 08:28:34 -0700 (PDT)
Received: by with SMTP id p3so108147610qtg.2 for <>; Mon, 31 Jul 2017 08:28:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zwMsJXdTPwZtLXDKVZ22I/LazxM/wOn111fYxfhAgss=; b=GzXM/TPu0nqFICgadIB2wZEZpWZyEylXIDzimmnfKbwT+mNNC5EMywAh/j3Pn9zcoX jFgqK1Tp5M/seLuCHbrnTTLPJni/sApvmOvkuMwfQVO8Lk5Lt1ONOh0i0LuiTHg95q2/ p2BJ0cjcJs9PugoJ40eCqh9W5FrAp15gwFEsHrNaAQCib7iMGcbeHVINmvTv2HIQ7LWL +7SOheFO1lUmPK4c6keu6UW4UZFS1rIMyJhYqMSZKUSsNpBIrn3anuiXri8WNdP66o+p Iuk/TbVavJe9S6to2VCxJFJniMuZ1tMOSJS7r9CL2wRR0DdKSZUG7Aul1LDVHTer+Z2L kGVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zwMsJXdTPwZtLXDKVZ22I/LazxM/wOn111fYxfhAgss=; b=ZF8/nqSWhccfzDnBr3beSbHf8pZ/F6kxV6qbG5jgqg3GsTi9Bnc4OmIVCu6DL1VCZP QysNucNOxMaZeZ3/DzO2ogoB9RixaWcO4IRQ97rB+86djAUyfecTcq22kb0zEP5KneBQ 6UOOqIukgtF2Mry7R+/D0lkwgPla7EfpoAKWH5ZnAb1+df6HmsHj8qhpY27MfZ/k37d9 aq4TmNOHBuFAeIvK4IrC5/c9kzfz6MjULVj8nbsFcAh2C5o9VAsim70OcVKgD9q6JH/j SeN7voY4pM3OElcz77RnsbS3dZrNfX/j+sLP/++PHXtZLnWJI65rsi7fjTzXvwbN7IMe Tsvw==
X-Gm-Message-State: AIVw1136E/RqnHT2x2UMqMASziUWLemTNVyqDy3tkv0Ze68FrXfcZyHP O76ldDHl0lmKaeEr
X-Received: by with SMTP id y17mr22724846qtb.207.1501514914059; Mon, 31 Jul 2017 08:28:34 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id r19sm15466758qtr.25.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 08:28:33 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_48DEE497-6B9E-4EE4-A35F-F9A930E520EE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 31 Jul 2017 11:28:32 -0400
In-Reply-To: <>
To: Michael Richardson <>
References: <>
X-Mailer: Apple Mail (2.3273)
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 15:28:36 -0000

On Jul 31, 2017, at 11:21 AM, Michael Richardson <>; wrote:
> The things that Ted wants, such "this the ID of the router", and the like,
> and this really the topic of the ANIMA BRSKI protocol.  It can be profiled
> to work in Homenet, provided that HNCP can elect a registrar.
> I think that is entirely workable, btw.
> I don't think that Homenet has to invent any protocols here.
> Is there a document for this Ted?  I will offer to help.

Your help would be much appreciated, but I don't know why there would be an election, so there's at a minimum some thinking to do there.   There is no document yet.

Also, bear in mind that a vendor-centric approach to this probably isn't going to work, because right now all the Homenet work I'm aware of is happening on OpenWRT and LEDE.   I'm sure that will change if we come up with something vendors want to deploy, but it has to work for the prototype case too.   And there's no particular reason to think that a PKI key from a vendor makes a device trustworthy.