Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

Kathleen Moriarty <> Fri, 20 November 2015 15:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 961761B32A5; Fri, 20 Nov 2015 07:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G2cERQOOk0UQ; Fri, 20 Nov 2015 07:17:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C8DF1B32A3; Fri, 20 Nov 2015 07:17:33 -0800 (PST)
Received: by wmec201 with SMTP id c201so76512245wme.0; Fri, 20 Nov 2015 07:17:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eTazFVq92GeBG0hjgVCEzXZFTMTeamKU6CRBcZJDI9I=; b=Xxg4cTdo8nNKxr7gyN0mVU8/l4mmhXbpKZMxXTdhFiCzfVDu+A+UWIN4gTxSWd1T4v hsRciBGZRMbYJsD8DwvfdNZ3e/GUpeFMeaorOngcY0r9xFL8Yp0qTXmfz6REEjektsVC hwwoQBQSyaBdm+6Wkecj6MgbiNkI9e0EKR2YAjQCN4zH7yRZG1Byow4uLuGgZs8OL2jQ xRLJkD0vlDJ2HhXzKtMlex+jUgmSjAnfDbqd+aVgjfmLUq1D5RNa4Mx74W0tisDdULj7 9EjGa8nSLxHPS2Vl3OL3PXQqp0nhu6NtKNFAm5zRcmtHgeSUSUnKbiUD4ubCdXNDAA98 u7aA==
MIME-Version: 1.0
X-Received: by with SMTP id t4mr15100469wjy.51.1448032651707; Fri, 20 Nov 2015 07:17:31 -0800 (PST)
Received: by with HTTP; Fri, 20 Nov 2015 07:17:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 20 Nov 2015 10:17:31 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Markus Stenberg <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Ted Lemon <>, "" <>
Subject: Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2015 15:17:34 -0000

Hi Markus,

Thanks for your quick response, inline,

On Fri, Nov 20, 2015 at 10:07 AM, Markus Stenberg
<> wrote:
> On 20.11.2015, at 16.47, Kathleen Moriarty <> wrote:
>>> It is question of threats <-> risks  <-> mitigation analysis. Only thing HNCP security really brings is _in case of insecure L2_ _some_ security for routing/psk state. If we assume every other protocol is secured (e.g. SEND, DHCPv6 ’secure mode’) it may be actually worthwhile, but as long as e.g. DHCPv4 is not secure (and it will never be I suspect), the amount of threats you actually take out of the picture by forcing ’securing’ HNCP alone is not really significant.
>>> To sum it up: I recommend still SHOULD MTI, MUST MTU _if and only if_ L2, but at least _my_ home does not _have_ any insecure L2, or at least insecure in a sense that HNCP running there would be my greatest worry.
>> If MTI is not a MUST, how can you MUST the MTU?
> The MUST MTU here is only for (relatively small) subset of U cases. Therefore, if a product (or a network) does not see those cases happening, broad MTI/MTU causes extra bloat without any benefit (like my home network case I mentioned).

Can you propose text that clearly describes this for developers and
implementors to replace the current text and we'll see where we are
at?  If it makes enough sense, I may be okay with that.  Stephen also
supported my discuss, so both of us may need to review and possibly
tweak it.  The current text isn't clear enough to convey what's been
described int his thread.

> For example, given Markus’ Home Network product does not support insecure (L2-wise) network, having MTI DTLS/TLS causes bloat and solves nothing and makes product harder to ship.
>> I think my question on what is "secure mode" and request for a
>> reference is still outstanding.
> Ah, sorry, simply too much mail backlog. ’secure mode’ in that context should be probably just secure _transport_ enabled on that particular link/for a particular remote endpoint, that is,  the {TLS,DTLS} based one described in the rest of the text.

OK, then for the text where this shows up in this draft, please do
replace it with what is meant exactly.

> I wonder if we should edit dncp too, I don’t think that term appears anywhere elsewhere in the document.

Yes, please.  Since it isn't defined anywhere, just stating what was
intended would be much better.

Thank you,

> Cheers,
> -Markus


Best regards,