Re: [Madinas] identities for legitimate devices

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 04 November 2020 22:43 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: madinas@ietfa.amsl.com
Delivered-To: madinas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67D13A10BE for <madinas@ietfa.amsl.com>; Wed, 4 Nov 2020 14:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUqo3b9wENhY for <madinas@ietfa.amsl.com>; Wed, 4 Nov 2020 14:43:35 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D9B3A10BA for <madinas@ietf.org>; Wed, 4 Nov 2020 14:43:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C5EC538AC6; Wed, 4 Nov 2020 17:43:38 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TJAQOQCgHfo0; Wed, 4 Nov 2020 17:43:37 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9EE338AC5; Wed, 4 Nov 2020 17:43:37 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 413E013CF; Wed, 4 Nov 2020 17:43:33 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "madinas@ietf.org" <madinas@ietf.org>
In-Reply-To: <3dddf745-2050-ed5a-2aaa-28765cc2a9c4@cs.tcd.ie>
References: <B8F9A780D330094D99AF023C5877DABAADB22346@dggeml511-mbs.china.huawei.com> <14818.1604508889@localhost> <7b63421e-a0f7-2dd4-0d0d-3f7c1f8fa3b9@cs.tcd.ie> <19468.1604517623@localhost> <3dddf745-2050-ed5a-2aaa-28765cc2a9c4@cs.tcd.ie>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Wed, 04 Nov 2020 17:43:33 -0500
Message-ID: <3469.1604529813@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/madinas/TE1y8K93ktLYGBgq6ocHK4kgVx4>
Subject: Re: [Madinas] identities for legitimate devices
X-BeenThere: madinas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: MAC Address Device Identification for Network and Application Services <madinas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/madinas>, <mailto:madinas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/madinas/>
List-Post: <mailto:madinas@ietf.org>
List-Help: <mailto:madinas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/madinas>, <mailto:madinas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2020 22:43:38 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
    > On 04/11/2020 19:20, Michael Richardson wrote:
    >> Is your objection based upon privacy implications of a device doing
    >> EAP-TLS with a home router?

    > I didn't make an "objection" - I noted that in many cases authorisation
    > without identification is possible and sufficient. I do think that, in
    > general, we ought be far slower than we are to try create new
    > identifiers or identifications, if those aren't needed. Indeed, MAC
    > address randomisation is an example of removing a long-lived hard-coded
    > hard-to-change identifier that no user even knows exists, and that's
    > one non-trivial reason to like MAC address randomisation.

Thank you.
And your skepticism is noted.

    > On 04/11/2020 18:03, mohamed.boucadair@orange.com wrote:
    >> I'm afraid that more is needed for the home network. Think about all
    >> the CPEs that display the map of connected devices (and that a user
    >> can manage), assign a static IP address for specific machines, program
    >> time slots when connectivity access is allowed for some devices,

    > I don't have any data on how many such CPEs are deployed, but
    > especially not on how much such features are used.  Data on that could
    > be a useful input to the discussion. I don't believe usage is common
    > for ISPs with which I'm familiar, but that could vary from place to
    > place and/or I could be wrong.

I think that that many of us techies are isolated from this kind of thing
because we deal with ISPs that don't force this on us.
These CPE features are becoming more common among ISPs that have a more
captive market, and it is because they can push things on relucant users.
Sometimes it's for their benefit, sometimes not.

    > On 04/11/2020 18:03, mohamed.boucadair@orange.com wrote:
    >> or future deployments where a specific DoH URI Template can be
    >> returned to one child PCs, etc.

    > I'm just making a wild guess here - but I'd say this BoF might be
    > easier if we avoid the third rail of DoH deployment arguments and leave
    > discussion of those to the ADD WG:-)

Yes, we don't have to discuss the plus or negative of a specific policy, but
we do need to agree that we need a hook on which to hang per-device policy.

I have regularly banned my child's devices by MAC address at certain times of
the evening ("school nights") to enforce no-screen-after-supper (But, he can
watch "TV" with us).
I have stopped this for three reasons:
  0) does bedtime have any meaning in a pandemic?
  1) I can not ban youtube while enabling google docs for school
  2) his phone has a data-SIM card, and the damn LTE provider won't give me
     a time-of-day-use-restriction
  3) nobody else knows how to override it on a single-use case basis
     [see #1]

I sure wish that there was a standard API for this.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide