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

Ted Lemon <> Wed, 18 November 2015 14:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51E441B2EA8; Wed, 18 Nov 2015 06:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e9rhFUlfsthP; Wed, 18 Nov 2015 06:56:20 -0800 (PST)
Received: from ( [IPv6:2a01:7e01::f03c:91ff:fee4:ad68]) by (Postfix) with ESMTP id B49541B2EAE; Wed, 18 Nov 2015 06:56:19 -0800 (PST)
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----sinikael-?=_1-14478585758520.22943157562986016"
From: Ted Lemon <>
In-Reply-To: <>
References: <> <>
Date: Wed, 18 Nov 2015 14:56:15 +0000
Message-Id: <>
MIME-Version: 1.0
Archived-At: <>
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: Wed, 18 Nov 2015 14:56:22 -0000

Wednesday, Nov 18, 2015 8:24 AM Juliusz Chroboczek wrote:
> HNCP is an amazingly flexible protocol, and one that will hopefully be
> used well beyond it's original area of application.  Many of the possible
> applications of HNCP don't require DTLS, either because the network is
> secured at a lower layer, or because they use a different application
> layer mechanism.

Which possible applications of HNCP don't require security?   The problem we have with HNCP is that we have no basis for establishing trust, not that we don't need security.

The argument against DTLS that I think makes some sense is "we don't know how to key it, and therefore don't know if it will work if/when we figure out security," not "we don't need it."   I actually have a great deal of sympathy for Kathleen's view here; if we make DTLS MTI, then at least we'll have an encryption/authentication mechanism when we figure out how we want to do that.

I think there's a pretty strong case to be made that the security mechanism will require public key cryptography.   If that's the case, then DTLS will work as an encryption/authentication layer.   The fact that the current draft refers to DTLS and makes it mandatory to use when transmitting pre-shared keys means that we've already got consensus that DTLS is a necessary option for encryption/authentication.

That being the case, I actually don't see any argument against making DTLS mandatory to implement.   You didn't give a reason for your opinion that we should not.   If you do have a reason for thinking that DTLS shouldn't be MTI, please state it plainly--your opinion may well be correct, but if we don't know why you have that opinion, we have no way to evaluate it other than to trust you or not, and that's not a good way to do standards work.   If the concern is whether there's a good DTLS implementation that can be used, I don't know how good it is but tinydtls looks like it might work.   It uses a license that is GPL-compatible.

Sent from Whiteout Mail -

My PGP key: