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

Ted Lemon <> Tue, 01 August 2017 00:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85CAF131828 for <>; Mon, 31 Jul 2017 17:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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] 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 UcF31OUHYL34 for <>; Mon, 31 Jul 2017 17:55:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0057812EC11 for <>; Mon, 31 Jul 2017 17:55:56 -0700 (PDT)
Received: by with SMTP id t37so1051882qtg.5 for <>; Mon, 31 Jul 2017 17:55:56 -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=ASlKC0gWsYsS/q4lEeptqpxmBC8pzOfZUa52mFO88Xs=; b=UoeVLss4GtIsMujJTXgYLz/3WnKnOJHIYARmxTAGseRSisE/x3qMe1Sg0ylTwG+OLO VWnCDEX8/aTRhZgsvdM2kGaGEE6g+apDu6PiOAMGQ9g/4FCZOoZSRoyUNcX8XfFOxquU pfnj2n6wjgDWi79BSMLkMzlu/Z8rKJToAcJuZ2to38HluIayc991I7G8LU5OCp1044hN yOi5NIGoH1TwMRBEy5IBfonxl/DHCHlttgtXQ5bEDtSi8d+Tph9wpDO1ID9yF3QgGsaW 8R/ontXcCS3m1EK0zJneKJJ1g9mehNLM+AExIcGgu8Njs97kM44K8pVt2sRhQDw9Zkk2 mVHw==
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=ASlKC0gWsYsS/q4lEeptqpxmBC8pzOfZUa52mFO88Xs=; b=Jp81VuF5myJCINcX8dMj8mAbxo7jMS7rGnvmIf1qV1v29TxlqGje1v7/baw7mgle5S pQf5uGkTvcxk4xvLhXxB6cIXMaY12WsQmMfjCtBKLCwcM1e74KcCTeG1lGyJXSL35r7m hiVunRp23OoFgoGadF9g3KEKxPZ1PBP/H4xgKlgordBsj9PVIyhJax4DZA+k/9dl7ucd Ri19Hq73BbhxdLVYyZPsnx9LCz9fa3KAZQ19TlB0CoVX5T83HHL+UjwaKlaIMaeCc7TH SSeu0qURYs4GoCVJyj6a3QVYHsseSDJ//0Sx1r7SGsW1csnR1YLrHkSdbJXK69Hh+nCg CZAQ==
X-Gm-Message-State: AIVw110co3mIOdrwphk6YYOl+xfh1dnlegnKf9hiJ+BoDAKLXGeHH5Se k/QajIeQCx2IwTKG
X-Received: by with SMTP id y49mr23666809qtc.313.1501548956073; Mon, 31 Jul 2017 17:55:56 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q4sm6306032qtf.78.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Jul 2017 17:55:55 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_16E466AF-FC51-43A9-833B-305CC43EC5DF"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 31 Jul 2017 20:55:53 -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: Tue, 01 Aug 2017 00:55:58 -0000

On Jul 31, 2017, at 8:20 PM, Michael Richardson <>; wrote:
>  a) do they really want this kind of traffic?
>  b) the certs issued will go into their cert transparency list, and I think
>     that means we lose privacy.
>  c) to make it work, they have to verify things.  IPv6 makes the
>     connectivity easy to arrange, but it seems like it's a big exposure for
>     the device.  We are talking more than just routers... I'm thinking
>     printers and all sorts of things.

Probably they don't, although they appear to be handling rather a lot of traffic already.   The problem is, we have no way to establish trust on a domain name because the browser vendors don't support DNSSEC-based TLS certs.   For some reason.   Not that I am bitter...

> It doesn't establish initial trust, it gives the user a trusted icon in their
> browser once we have initial trust.

Blrk.   I just don't think it's a good idea to burn certs into routers.   And I don't want the end user to be relying on their router vendor for their PKI.   But I will admit that I haven't done a thorough threat analysis, so I can't justify my collywobbles.

>    The Pledge can choose to accept vouchers using less secure methods.
>    These methods enable offline and emergency (touch based) deployment
>    use cases:

That ain't going to work.   But we can probably figure something out.

> Christian's comments in DNSSD (which I also watched today) is right though:
> for many applications in *discovery* is important you probably don't want
> certs, because they reveal too much, and the relationship is too ephermeral.
> The link between Dave's Laptop and Dave's Cool Printer is probably longer.

Indeed, but we don't want Dave's Laptop going around asking for Dave's Cool Printer when Dave's Laptop is not on the home network where Dave's Cool Printer lives.