Re: [homenet] security work items - what do we want to do?

Michael Richardson <> Wed, 31 January 2018 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8640A12EB51 for <>; Wed, 31 Jan 2018 07:03:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rQK7mbmRjUlt for <>; Wed, 31 Jan 2018 07:03:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66F6312EB73 for <>; Wed, 31 Jan 2018 07:01:12 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id D4E4420093; Wed, 31 Jan 2018 10:07:19 -0500 (EST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id A891380222; Wed, 31 Jan 2018 10:01:10 -0500 (EST)
From: Michael Richardson <>
To: Andrew Sullivan <>
In-Reply-To: <>
References: <> <> <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; 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: Wed, 31 Jan 2018 10:01:10 -0500
Message-ID: <>
Archived-At: <>
Subject: Re: [homenet] security work items - what do we want to do?
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: Wed, 31 Jan 2018 15:03:31 -0000

Andrew Sullivan <> wrote:
    >> On 24/01/18 13:32, Michael Richardson wrote:
    >> >
    >> > b) DNS naming and delegation in Last Call.

    > All of it, or just the simple one?  I think the timeframe for "simple"
    > is "soonish" and the "real" one from the architecture document might
    > well be "heat death of the universe".  Also, I think the "real" one is
    > going to interact badly with a number of security issues, so I am not
    > too convinced that we will be able to do the "real" one without
    > working some on the use cases.

I think it's sufficient for the WG to think that we got something done, and
if we split up the work and defer it, then fine.  If we need security work to
make the more "real" one work right, then that's good *input* to the security
work, and we could have an ID with an empty section that waits for awhile,
but we have otherwise reached WG consensus on.

    >> Reasonable points. Do others (dis)agree?

    > Only a little:

    >> other bits of work need to be fully finished - if we know
    >> what kind of keying that'll be used in the final results,
    >> we could make some progress, but I do agree we'd need to

    > I disagree to the extent I agree with the above.  That is, I think it
    > is reasonable to work on things as it starts to be clear what else we
    > can rely on.

It sounds like we should write a security "results" document.
This would be a kind of requirement document on the security work, but more
to the point, it would detail what other work could depend upon.

{ps: the AmazonEcho/GoogleHome/Mycroft/etc. devices seem like ideal platforms
     to be the root of a secure network. I suspect that there are boostrap
     issues with the ones that do all the processing in the cloud}

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-